п ротокол ICMP (Internet Control Message Protocol- протокол управляющих сообщений Internet) был задуман как безопасное средство для уведомления об ошибках, а также для выдачи несложных запросов и ответа на них. Возможно, именно из-за простоты его реализации современные способы использования ICMP в собственных корыстных целях кажутся особенно возмутительными. В своем естественном виде ICMP является сравнительно простым и строгим протоколом, но с помощью некоторых модификаций может служить для осуществления коварных планов злоумышленников. Поэтому особенно важно уметь различать нормальное и нестандартное использование этого протокола.

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

Теория ICMP

До того как изучать примеры ICMP-сообщений, рассмотрим несколько общих принципов работы протокола ICMP. Те, кто считают, что достаточно осведомлены о теории ICMP, могут сразу же переходить к разделу “Методы составления схемы сети”.

Зачем нужен ICMP

Как говорилось в гдаве 2, “TCPdump и TCP”, TCP является протоколом, ориентированным на установление соединений, и для надежной доставки TCP-

сегментов требуются значительные ресурсы вычислительных систем. Протокол UDP не ориентирован на установление соединений и не гарантирует надежной доставки данных. Для работы обоих протоколов необходим свободный порт сервера, с которым может взаимодействовать клиент.

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

Кроме того, как маршрутизаторы или хосты должны уведомлять отправителя о возникновении той или иной ошибки при доставке сообщения? Достаточно надежный протокол TCP способен указывать причины некоторых ошибок, например, отправку данных на закрытый порт с помощью возвращения TCP-пакетов с установленными флагами RESET и АСК. Если TCP-клиент или сервер получает слишком много информации, то предусмотрен механизм закрытия буфера входящих сообщений с помощью уменьшения размера окна до значения 0. Это будет указывать на неспособность хоста-получателя принимать следующие порции данных, пока не будут обработаны данные из буфера.

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

Область применения ICMP

Рассмотренная в главе 1, “Фундамент Internet”, многоуровневая модель стека протоколов TCP/IP определяет обмен данными между двумя хостами на различных уровнях (рис. 4.1).

Рис. 4.1. Многоуровневая модель стека TCP/IP

На самом высоком уровне работают TCP/IP-приложения, например telnet. На следующем транспортном уровне с помощью протоколов TCP и UDP осуществляется взаимодействие между хостами. Ниже расположен уровень Internet (сетевой), на котором обеспечивается доставка дейтаграмм по адресу назначения. Последним уровнем стека протоколов TCP/IP является канальный уровень, ответственный за физическую доставку дейтаграммы по сети.

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

Свойства ICMP

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

Типы 1СМР-С00бщений

Перечисление и изучение всех возможных ICMP-сообщений выходит за рамки данной книги. Тем, кто хочет получить более подробную информацию по данной теме, рекомендуем обратится по адресу www.iana.org/assignments/icmp-parameters.

Для ICMP практически не существует понятий “клиент” или “сервер”. Действительно, при доставке ICMP-сообщений об ошибке хост-получатель может учитывать это уведомление, но ничего не сообщать об этом отправителю. Кроме того, ICMP не предоставляет никаких гарантий доставки сообщений.

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

Еще одной уникальной возможностью ICMP является поддержка широковещательного трафика. Протокол TCP требует установления единственного соединения клиент-сервер, a ICMP позволяет отправлять данные сразу нескольким адресатам. Как будет показано в разделе “Атака Smurf’, эта возможность может быть успешно использована злоумышленниками.

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

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

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

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

Резюме теоретических сведений

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

ICMP является уникальным протоколом, так как для доставки сообщений не использует портов. Допускается потеря ICMP-сообщений. ICMP-сообщения могут быть широковещательными, так как единственное соединение с определенным хостом не устанавливается.

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

Методы составления схемы сети

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

Атака злоумышленника, который не составил схемы сети, приведет к резкому увеличению сетевого трафика, т.е. не будет действительно эффективной. В последнем квартале 1999 года была проведена подобная атака сканирования, которая напомнила поговорку “как слон в посудной лавке”. Троянская программа RingZero, поражавшая компьютеры под управлением Windows, выполняла сканирование хостов на предмет открытых портов ргоху-серверов. Основным недостатком ее работы было сканирование случайных хостов, работающих в различных сетях. Поэтому выполнялось сканирование как по действительным, так и по несуществующим IP-адресам. Такие действия быстро выявлялись системами обнаружения вторжений. Кроме того, для извлечения полезной информации о проведенном сканировании приходилось выполнять большой объем лишней работы. Если бы атака была более направленной, и все сканируемые IP-адреса принадлежали бы активным компьютерам, то нарушитель, несомненно, добился бы больших результатов.

Троянская программа RingZero

В зарегистрированной атаке RingZero на защищенную сеть было обнаружено, что сканирование проводилось по множеству IP-адресов, причем сканировались большей частью неактивные ТСР-порты: 3128 (ргоху-сервер Squid), 80 (стандартный HTTP-порт) и 8080 (альтернативный HTTP-порт). В наблюдаемой сети класса В выполнялось около шести таких сканирований каждый час. Сообщения о выявлении данной атаки поступили от множества других узлов Internet.

Первым предположением было, что при данной атаке были использованы подложные IP-адреса, а цель ее неизвестна. Но, Рон Маркум (Ron Marcum), системный администратор Университета Вандербильта, обнаружил в своей сети компьютер под управлением Windows, выполняющий данное сканирование. Процессом сканирования управляла программа под именем RingZero. Программа RingZero была подробно рассмотрена на конференции SANS (System Administration, Networking and Security - системное администрирование, работа в сети и безопасность), проходившей в октябре 1999 года.

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

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

В разделе “Сканирование с помощью АСК-пакетов” главы 2, “TCPdump и TCP”, показано, как с помощью TCP-пакетов с установленным флагом АСК можно выявить работающие хосты. Этот метод - достойная альтернатива сканированию с помощью эхо-запросов. В следующих разделах рассмотрен ряд обычных и нестандартных методов сканирования.

Неутомимый составитель схем

Ниже представлен отчет о классическом сканировании для составления схем сетей с помощью отправления отдельных эхо-запросов ICMP всем хостам определенной подсети. В данном случае сканируется сеть класса С 192.168.117. Выявить такое сканирование не составляет труда.

00:05:58.560000 scanner.net > 192.168.117.233: icmp: echo request

00:06:01.880000 scanner.net > 192.168.117.139-. icmp: echo request

00:12:45.830000 scanner.net > 192.168.117.63: icmp: echo request 00:15:36.210000 scanner.net > 192.168.117.242: icmp: echo request

00:15:58.600000 scanner.net > 192.168.117.129: icmp: echo request

00:18:51.650000 scanner.net > 192.168.117.98: icmp: echo request 00:20:42.750000 scanner.net ? 192.168.117.177: icmp: echo request

00:26:36.680000 scanner.net > 192.168.117.218: icmp: echo request

00:05:58.560000 scanner.net > 192.168.117.233: icmp: echo request

Тем не менее даже такое сканирование может остаться незамеченным, если на узле не контролируется ICMP-трафик. Тут возникает риторический вопрос: если хакер сканирует всю сеть, но никто за этим не следит, то будет ли поднята тревога? Если считать подозрительным каждый одиночный эхо-запрос, то системы обнаружения вторжений поднимали бы тревогу слишком часто, поэтому одиночные эхо-запросы, как правило, игнорируются. Тем не менее система обнаружения вторжений, которая отслеживает все попытки сканирования, способна выявить сканирование при отправке большого числа одиночных запросов с одного хоста. Другими словами, система обнаружения вторжений контролирует количество попыток подключения с одного IP-адреса за установленный период времени (например, не более семи соединений в час). Поэтому приведенное выше сканирование будет обнаружено.

Эффективное составление схем

Рассмотренное в предыдущем примере сканирование, скорее всего, выполнялось автоматически с помощью простой программы. Но зачем нужны лишние действия, если протокол ICMP позволяет организовать широковещательную отправку запросов и проверить активность многих хостов с помощью нескольких команд? Именно такую возможность использует программа сканирования, отчет о действиях которой представлен ниже.

13:51:16.210000 scanner.net > 192.168.65.255: icmp: echo request 13:51:17.300000 scanner.net > 192.168.65.0: icmp: echo request 13:51:18.200000 scanner.net > 192.168.66.255: icmp: echo request 13:51:18.310000 scanner.net > 192.168.66.0: icmp: echo request 13:51:19.210000 scanner.net > 192.168.67.255: icmp: echo request 13:53:09.110000 scanner.net > 192.168.67.0: icmp: echo request 13:53:09.940000 scanner.net > 192.168.68.255: icmp: echo request 13:53:10.110000 scanner,net > 192.168.68,0: icmp: echo request 13:53:10.960000 scanner.net > 192.168,69.255: icmp: echo request 13:53:10 . 98 0000 scanner.net > 192.168.69.0: icmp: echo request

Как видим, составляется схема подсети 192 .168. Здесь представлен только фрагмент полного сканирования, в котором значения третьего байта IP-адреса изменяются от 65 до 69. В качестве значения последнего байта используется или 0, или 255. Значение 255 - стандартный адрес для широковещательного пакета, а 0 - широковещательный адрес для хостов, в которых стек протоколов TCP/IP работает под управлением операционной системы BSD UNIX (Berkeley Software Distribution). При использовании в ICMP-запросах обоих этих широковещательных адресов должны ответить все активные хосты исследуемой сети.

Можно сделать вывод о том, что в своей сети лучше запретить любые действия с использованием широковещательных адресов. Лично мне не известны другие законные операции при рассылке широковещательных запросов, кроме как проверки работы компьютеров. Кроме того, запрещение широковещательного трафика предотвратит распространение атаки Smurf за счет ресурсов вашей сети (см. раздел “Атака Smurf’).

Искусное составление схем

Следующий листинг дает представление о новом варианте уже рассмотренного метода составления схемы сети.

06:34:31.150000 scanner.net > 192.168.21.0: icmp: echo request 06:34:31.150000 scanner.net > 192.168.21.63: icmp: echo request 06:34:31.150000 scanner.net > 192.168.21.64: icmp: echo request 06:34:31.150000 scanner.net > 192.168.21.127: icmp: echo request 06:34:31.150000 scanner.net > 192.168.21.128: icmp: echo request 06:34:31.150000 scanner.net > 192.168.21.191: icmp: echo request

06:34:31.150000 scanner.net > 192.168.21.192: icmp: echo request 06:34:31.150000 scanner.net > 192.168.21.255: icmp: echo request

Рассмотрим данный метод сканирования. Эхо-запросы ICMP были отправлены в подсеть класса С 192.168.21. Обратите внимание на последний байт использованных IP-адресов. Как видим, первый запрос был отправлен по широковещательному адресу 0, а последний - по широковещательному адресу 255. Эти адреса уже применялись в предыдущем методе сканирования.

Но в данном случае запросы отправляются еще и по другим IP-адресам, при этом используются первое и последнее значение промежутка в 64 IP-адреса. Например, первый IP-адрес заканчивается байтом со значением 0, а следующий за ним - байтом со значением 63. Почему используется именно такой интервал в 64 адреса?

Согласно стандарту сеть класса С имеет 256 IP-адресов в диапазоне от 0 до 255. С помощью маски подсети эту сеть можно разделить на несколько подсетей, и одним из вариантов является создание четырех независимых подсетей по 64 IP-адреса каждая. При этом соответственно изменяются широковещательные адреса для каждой подсети, которые и были использованы в данном примере. Таким образом, при составлении схемы учитывается возможность существования “нестандартной” схемы сети класса С. Если в исследуемой сети действительно было использовано указанное разделение, то ответили бы все активные хосты. То же самое произойдет и при сканировании стандартной сети класса С (в которой не запрещено использование широковещательных адресов), так как применяются широковещательные адреса 0 и 255.

Интеллектуальное составление схемы

В этом последнем отчете о сканировании с целью составления схемы сети показано использование другого типа ICMP-запросов. ICMP-запрос маски адреса (address mask request) предназначен для получения маски подсети, в которой установлен запрашиваемый хост. Помните, как в прошлом примере основной целью сканирования было угадать схему адресации сети? Данный метод позволяет устранить лишние проблемы.

20:39:38.120000 scanner.edu > router.com: icmp: address mask request (DF) 20:39:38.170000 router.com > scanner.edu: icmp: address mask is OxffffffOO (DF)

20:39:39.090000 scanner.edu > router2.com: icmp: address mask request (DF)

20:39:39.230000 router2.com > scanner.edu: icmp: address mask is OxffffffOO

(DF)

20:39:38.120000 scanner.edu > routerx.com: icmp: address mask request (DF)

20:39:38.170000 routerx.com > scanner.edu: icmp: address mask is OxffffffOO

(DF)

Этот метод нельзя назвать классическим методом составления схемы сети, но он позволяет провести предварительную разведку и определить маски подсетей различных маршрутизаторов. Как правило, на запросы о масках подсетей отвечают только маршрутизаторы, поэтому нарушитель получает адреса наиболее интересных для исследования хостов. Как говорилось в главе 1, “Фундамент Internet”, с помощью маски подсети можно узнать, сколько битов IP-адреса отведено для указания сети, а сколько - для хоста.

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

IP-адреса, использованный в данном случае ICMP-запрос позволяет выявить сети, в которых применяются нестандартные маски. Такую информацию невозможно получить при изучении только IP-адреса. В этом примере сканируемые маршрутизаторы отвечают на запрос шестнадцатеричным числом Oxf f f f f f 00. Десятичное значение этого числа составляет маску подсети 255.255.255.0, т.е. все хосты принадлежат сети класса С. Для обеспечения безопасности ответы маршрутизаторов на ICMP-запросы о масках подсети следует запрещать.

Резюме о составлении схемы сети

Итак, существуют следующие методы составления схемы сети:

■ отправка эхо-запросов ICMP отдельным хостам сети;

■ отправка эхо-запроров ICMP по широковещательным адресам сети;

■ отправка эхо-запросов ICMP по широковещательным адресам сети и вероятных подсетей;

■ отправка некоторым хостам сети ICMP-запросов о маске подсети с целью выявления наиболее интересных целей сканирования.

Стандартные ICMP-сообщения

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

Хост недостижим

Следующий отчет содержит информацию о получении хостом sending. host ICMP-сообщения об ошибке при доставке отправленного им пакета хосту target.host.

router > sending.host: icmp: host target.host unreachable

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

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

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

Порт недостижим

Рассмотрим случай, когда хост-получатель с помощью ICMP-сообщения уведомляет отправителя о том, что на указанный UDP-порт запросов не ожидается. В данном случае пакет был отправлен на NTP-порт (Network Time Protocol - протокол синхронизации сетевого времени) получателя.

target.host > sending.host: icmp: target.host udp port ntp unreachable (DF)

Для доставки сообщения об ошибке используется протокол ICMP. Не забывайте, что протокол TCP использует другой способ уведомления отправителя о том, что запрошенный порт закрыт. С этой целью отправителю возвращается ТСР-сегмент с установленным флагом RESET. Протокол UDP не обладает подобной возможностью, поэтому на помощь привлекается ICMP.

И снова мы видим, что данное ICMP-сообщение об ошибке предоставляет ценную информацию. Все сканируемые UDP-порты, которые не ответили на запрос стандартным ICMP-сообщением port unreachable, возможно, являются открытыми. Но есть вероятность, что ответа не последовало из-за банальной потери пакета. Кроме того, сообщения о недостижимости порта могут быть заблокированы для передачи за пределы локальной сети. Таким образом, отсутствие ICMP-сообщения о недостижимости указанного UDP-порта еще не дает гарантии, что на этом порту работает какая-либо служба.

Запрещено администратором

В следующем примере содержится отчет о еще одном ICMP-уведомлении об ошибке.

router > sending.host: icmp: target.host unreachable - admin prohibited

В данном случае хост-отправитель пытался передать пакет хосту target. host. Маршрутизатор (router) работает как шлюз для сети получателя.

В списке контроля доступа маршрутизатора установлены ограничения на передачу в локальную сеть определенного трафика. Этот трафик, например, предназначен заблокированному порту, а может быть заблокирован прием пакетов от хоста с определенным IP-адресом или от компьютеров какой-то сети, или же установлена защита на доступ к определенному компьютеру или подсети. В любом случае маршрутизатор может ответить ICMP-сообщением “unreachable - admin prohibited” (недостижимо - запрещено администратором). Хотя в этом сообщении и не указан объект блокирования (например, порт получателя или IP-адрес отправителя), но проницательный нарушитель может использовать различные варианты установки соединения, чтобы выявить истинную причину блокирования. Затем он постарается найти другие незащищенные пути проникновения в сеть.

Необходима фрагментация

Еще одно ICMP-сообщение позволяет уведомить отправителя о невозможности доставки дейтаграммы по указанному адресу без ее фрагментации, router > sending.host: icmp: target.host unreachable - need to frag (mtu 1500)

Выражение DF в отчете TCPdump означает, что был установлен флаг Don’t Fragment (“не фрагментировать”), указывающий на запрещение фрагментации данной дейтаграммы. Если дейтаграмма с этим флагом должна пройти через сеть, в которой требуется ее фрагментация, то маршрутизатор выявляет проблему, отбрасывает дейтаграмму и возвращает отправителю ICMP-сообщение об ошибке (need to frag).

Данное ICMP-сообщение содержит значение максимальной единицы передачи данных (MTU) сети, в которой требуется фрагментация дейтаграммы. Некоторые хосты намеренно отправляют пробную дейтаграмму с установленным флагом DF, чтобы узнать минимальное значение MTU на пути к получателю. Если возвращаемое ICMP-сообщение указывает наименьшее значение MTU на всем пути, то отправитель может установить размер дейтаграммы, который бы позволил обойтись без фрагментации. Избегать фрагментации следует в связи с большими расходами ресурсов при потере хотя бы одного фрагмента из последовательности.

Превышение лимита времени

ICMP-сообщение time exceeded in-transit информирует отправителя о чрезмерно долгом пребывании его дейтаграммы в Internet, routerx > sending host: icmp: time exceeded in-transit

Протокол IP должен иметь возможность удалить из Internet потерянную дейтаграмму, которая, возможно, бесцельно и бесконечно передается по замкнутому маршруту между несколькими маршрутизаторами. Необходимость отбрасывания потерянных дейтаграмм определяет значение поля TTL (time-to-live - время жизни) в заголовке 1Р-дейтаграммы.

При отправке дейтаграмм в различных операционных системах задаются различные значения поля TTL. Узнать эти стандартные значения можно, обратившись по адресуhttp://project.honeynet.org/papers/finger/traces.txt.

При прохождении дейтаграммы через маршрутизаторы на пути к получателю каждый маршрутизатор уменьшает значение поля TTL на 1. Когда значение этого поля станет равным 0, маршрутизатор отбрасывает дейтаграмму и возвращает ICMP-сообщение time exceeded in-transit хосту-отправителю. В главе 5, “Воздействия и реакции”, рассказано, как с помощью этих ICMP-сообщений и утилиты Traceroute выявляются промежуточные маршрутизаторы на пути прохождения пакетов по сети до места назначения.

Информация ICMP-сообщений об ошибках

Важно понять, что в возвращаемой дейтаграмме с ICMP-сообщением об ошибке предоставляется дополнительная информация. В частности, после самого ICMP-сообщения возвращается заголовок IP-дейтаграммы и 8 байт заголовка вложенного пакета и данных оригинальной дейтаграммы, которая вызвала ошибку (рис. 4.2). Эта информация предназначена для того, чтобы хост-отправитель смог идентифицировать недошедшую дейтаграмму и внести коррективы в процесс ее отправки. Согласно документу RFC 1122 ответа на полученное ІСМР-сообщение об ошибке не требуется.

Кроме того, не следует ожидать, что все операционные системы будут точно возвращать ІР-заголовок и следующие за ним 8 байт информации первоначальной дейтаграммы. Логично предположить, что в возвращаемую дейтаграмму после ІСМР-сообщения об ошибке всегда скопируются те же первые 28 байт, что не удалось доставить в исходной дейтаграмме. На самом деле, с помощью программы nmap возможно определение операционной системы удаленного хоста по результатам его ответов на нормальные и нестандартные пакеты. Все операционные системы отвечают по-разному, что позволяет провести классификацию ответов. Одним из тестов в серии пакетов, предназначенных сканируемому хосту, является попытка отправить дейтаграмму на закрытый UDP-порт. При этом целью является возврат ІСМР-сообщения “port unreachable”. Программа nmap исследует заголовок IP-дейтаграммы этого сообщения и следующие 8 байт данных начального пакета. С помощью сравнения полей в полученном сообщении с полями исходной дейтаграммы nmap идентифицирует операционную систему удаленного хоста.

Рис. 4.2. Формат ICMP-сообщения об ошибке

Резюме о стандартном использовании ICMP

Мы рассмотрели только несколько ICMP-сообщений, которые могут быть зарегистрированы при анализе сетевого трафика. Существует множество других IPCM-сообщений об ошибках, также предоставляющих полезные сведения. Их могут отправлять как хосты, так и маршрутизаторы. /

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

Использование ICMP для проведения атак

Нет ничего удивительного в том, что ICMP, как другие протоколы, стал использоваться с дурными намерениями. В настоящее время ICMP применяется в различных типах атак отказа в обслуживании, а также в качестве самого надежного средства для проведения скрытого сканирования. В этом разделе мы рассмотрим эти и другие примеры вредоносного использования ICMP.

Гололедица

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

Очень часто, анализируя трафик, предназначенный нашим узлам, у меня возникало это ощущение невидимой угрозы. На личном опыте я убедился в настойчивости, хитрости и сообразительности, с которыми Internet-пираты добиваются своих целей. Для каждого специалиста в области сетевой безопасности основным вопросом должен стать вопрос “Чего я не заметил?”. Если проявить беспечность по отношению к защите своего Web-узла, то однажды он может выйти из-под контроля по неизвестной причине.

Атака Smurf

Атака Smurf (рис. 4.3) основана на использовании возможности протокола ICMP рассылать дейтаграммы по нескольким адресам. Ответить на один широковещательный эхо-запрос ICMP может большое количество хостов. Эта возможность используется для проведения атаки отказа в обслуживании на избранный хост или сеть.

Сначала злоумышленник должен сформировать широковещательный эхо-запрос ICMP к хостам атакуемой сети, подменив при этом действительный IP-адрес своего компьютера.

Рис. 4.3. Схема атаки Smurf

В качестве этого 1Р-адреса используется адрес атакуемого хоста (или сети). Чтобы запрос попал ко всем хостам сети, его должен пропустить внешний маршрутизатор. Успешным завершением атаки является отправка всеми работающими хостами эхо-ответов на адрес атакуемого хоста. Атакованный хост (или сеть, в которой он находится) может пострадать от такой внезапной активности и перестанет выполнять возложенные на него задачи при следующих условиях:

■ нарушитель отправляет большое количество широковещательных эхо-запросов;

■ внешний узел (маршрутизатор) позволяет прохождение входящего трафика с указанием широковещательного адреса;

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

■ канал, с помощью которого атакуемый узел соединен с Internet, имеет низкую пропускную способность. Точнее, количество одновременно отправленных пакетов должно превысить максимальную пропускную способность этого канала. Хотя можно “затопить” пакетами любое Internet-соединение при наличии достаточного трафика, но для соединений с меньшей пропускной способностью сделать это будет проще.

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

Атака Tribe Flood Network

Атака Tribe Flood Network (TFN) является еще одной атакой отказа в обслуживании, в которой используются ІСМР-сообщения (рис. 4.4). В отличие от атаки Smurf, организуемой с одного компьютера с применением одной сети для ее распространения, атака TFN использует большое количество распределенных хостов. Эти хосты часто называют хостами-демонами. Поэтому термин распределенная атака отказа в обслуживании (DDoS) наиболее точно определяет использование нескольких рассредоточенных в Internet хостов для совместного осуществления атаки.

Рис. 4.4. Схема атаки Tribe Flood Network

Для проведения этой атаки требуется установка программы на ведущем компьютере- “мастере” TFN и на нескольких агентах- хостах-демонах TFN. Как правило, в качестве хостов-демонов используются скомпрометированные компьютеры. Мастер TFN дает хостам-демонам команду на атаку (часто одновременную) избранной цели. Взаимодействие между мастером и хостами-демонами осуществляется с помощью эхо-ответов ICMP. Демоны TFN могут организовать UDP-наводнение, SYN-наводнение, наводнение эхо-запросами ICMP или атаку Smurf.

Мастер информирует хосты-демоны о начале атаки с помощью эхо-ответов ICMP. При этом тип атаки определяется по значению поля идентификации в ICMP-заголовке эхо-ответа. В области данных такого эхо-ответа передаются необходимые аргументы.

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

Как вы уже, наверно, догадались, одновременное использование нескольких распределенных хостов для наводнения пакетами избранной цели позволит провести успешную атаку отказа в обслуживании против хоста или сети. Чтобы получить более подробную информацию об атаке TFN, зайдите на сайт www. cert. org и обратитесь к отчету об инциденте IN-99-07.

Самостоятельно организованный отказ в обслуживании

Это было 29 декабря 1999 года. Приступая к работе в центре Y2K (проблема 2000 года), расположенном в резиденции министра обороны, я размышлял над слухами о грядущем компьютерном апокалипсисе. Большинство полагало, что будут проведены массированные атаки отказа в обслуживании, направленные против транспортных и энергетических служб. Несмотря на заверения хакеров о том, что они будут праздновать Новый год вместе со всеми, преобладало мнение, что появление средств для распределенных атак отказа в обслуживании приурочено именно к наступлению 2000 года.

Реакцией на эту угрозу стало закрытие многих сайтов и ограничение доступа ко многим сетям. Парадоксальность этой ситуации подчеркнула фраза одного из наших сотрудников: “Забавно, что, защищаясь от атаки отказа в обслуживании, они сами отключают собственные службы”.

Атака WinFreeze

Атака WinFreeze, по существу, заставляет избранный компьютер атаковать самого себя.

router > victim.com) icmp: redirect 243.148.16.61 to host victim.com

router > victim.com: icmp: redirect 110.161.152.156 to host victim.com

router > victim.com: icmp: redirect 245.211.87.115 to host victim.com

router > victim.com: icmp: redirect 49.130.233.15 to host victim.com

router > victim.com: icmp: redirect 149.161.236.104 to host victim.com

router > victim.com: icmp: redirect 48.35.126.189 to host victim.com

router > victim.com: icmp: redirect 207.172.122.197 to host victim.com

router > victim.com: icmp: redirect 113.27.175.38 to host victim.com

router > victim.com: icmp: redirect 114.102.175.168 to host victim.com

С помощью ICMP-сообщения redirect хост-отправитель уведомляется о выборе для доставки сообщения неоптимального маршрутизатора и о необходимости добавить адрес оптимального маршрутизатора в таблицу маршрутизации. При наводнении этими ICMP-сообщениями о перенаправлении атака WinFreeze может вызвать отказ в обслуживании уязвимого хоста, работающего под управлением Windows NT. Атака выполняется в сети атакуемого компьютера, а ICMP-сообщения приходят от имени маршрутизатора этой сети. При получении массы сообщений redirect атакованный хост пытается внести изменения в таблицу маршрутизации, и ресурсы центрального процессора в основном тратятся на обработку поступающих пакетов.

В этом примере маршрутизатор router заставляет хост victim, com перенаправить отправляемые им (хостом) пакеты на самого себя. В результате при попытке внести многочисленные изменения в таблицу маршрутизации хост victim. com может не справиться с другими возложенными на него задачами.

Программа Loki

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

Loki использует ICMP в качестве туннельного протокола для создания скрытого канала связи. Скрытым каналом (covert channel) называют канал, использующий метод передачи данных или поле дейтаграммы нестандартным способом для осуществления незаконных действий. Другими словами, ICMP выступает как транспортный протокол, а программа Loki работает по стратегии клиент-сервер. Если на скомпрометированном хосте установлен сервер Loki, то он будет отвечать на запросы Loki-клиента. Например, клиент Loki может послать запрос cat/etc/passwd, чтобы получить файл паролей. Пользователю компьютера, на котором работает клиент Loki выводится на дисплей содержимое запрошенного файла, он может его сохранить и попытаться взломать. Более подробную информацию о программе Loki можно получить по адресу www. phrack. com (выпуск 49, статья 6).

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

Незатребованные эхо-ответы

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

reply.com > 192.168.127.41: icmp: echo reply

reply.com > 192.168.127.41: icmp: echo reply

reply.com > 192.168.127.41: icmp: echo reply

reply.com > 192.168.127.41: icmp: echo reply

reply.com > 192.168.127.41: icmp: echo reply

reply.com > 192.168.127.41: icmp: echo reply

Что мы видим? Хост reply.com отправляет хосту 192.168.127.41 поток эхо-ответов ICMP. Все было бы нормально, если бы хост 192.168.127.41 отправлял эхо-запросы для возвращения данных ответов. Но это не так, никаких эхо-запросов с хоста 192.168.127.41 не отправлялось. Зачем это кому-то нужно? Возможные причины таких действий изложены в трех следующих разделах.

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

Предположение 1: подмена IP-адреса

Первое предположение при получении отчета о подобном трафике - кто-то подменил IP-адрес своего хоста IP-адресом 192.168.127.41 и отправил серию эхо-запросов на хост reply.com. В результате хост reply.com возвращает эхо-ответы указанному отправителю. Если эхо-ответы приходят от многих компьютеров, работающих в той же сети, что и reply, com, это означает, что компьютер reply. com стал целью атаки Smurf.

В последнее время объем действий с использованием подмененных IP-адресов резко увеличился, поэтому наше первое предположение наиболее вероятно. Как правило, если получение незатребованных эхо-ответов ICMP связано с подменой IP-адреса вашего хоста (в этом примере 192.168.127.41), то от этого же хоста (в данном случае reply. com) поступает и другая незапрошенная информация. Обычно эти эхо-ответы отправляются нескольким хостам локальной сети (в нашем случае один и тот же эхо-ответ повторяется много раз).

Предположение 2: атака TFN

Предположим, что проводится атака TFN. Как известно, “хозяин” TFN взаимодействует с демонами TFN с помощью эхо-ответов ICMP.

Следовательно, причиной получения незапрошенных эхо-ответов могло стать использование хоста 192.168.127.41 в качестве демона TFN. Хотя значение поля идентификационного номера ICMP используется, чтобы указать хосту-демону начало атаки TFN определенного типа, все же точно описать смысл этого значения невозможно, так как хакер мог изменить исходный код программы атаки. Определить, не стал ли данный хост демоном TFN, проще по исходящему от этого хоста трафику после получения незапрошенных эхо-ответов ICMP. Если он отправляет большой объем информации непонятного предназначения, значит, скорее всего, он участвует в атаке TFN.

Предположение 3: Loki

Последнее из вероятных предположений заключается в вероятном обмене информацией между клиентом и сервером Loki. При этом вполне возможно, что на каждый эхо-запрос ICMP генерируется несколько эхо-ответов.

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

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

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

Резюме о незаконном использовании ICMP

Подводя итоги этого раздела, можно сказать, что протокол ICMP может применяться не только для нормальных, но и для вредоносных операций, например для атак отказа в обслуживании (Smurf и WinFreeze). В атаке TFN этот протокол служит, скорее, в качестве транспортного средства, предоставляющего возможность для проведения еще одного типа атак отказа в обслуживании. Программа Loki вообще превращает ICMP в туннельный протокол для проведения атакующих действий.

Блокировать или не блокировать

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

■ “protocol unreachable”;

■ “port unreachable”;

■ “IP reassembly time exceeded”;

■ “parameter problem”;

■ “echo replay”;

■ “timestamp replay”;

■ “address mask replay”.

Кроме того, если маршрутизатор сети будет уведомлять отправителя об ошибках недостижимости некоторых хостов (host unreachable), то, предположив активность всех остальных хостов, можно составить схему сети.

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

■ “fragmentation needed but don't-fragment bit set”;

■ “admin prohibited”;

■ “time exceeded in transit”;

■ “network unreachable”;

■ “host unreachable”.

И, наконец, дополнительную информацию можно узнать из перечисленных ниже ICMP-сообщений:

■ “admin prohibited” - позволяет узнать о типе блокируемого трафика;

■ address mask replay” - предоставляет значение маски подсети, в которой установлен запрошенный хост;

■ “time exceeded in transit” используется утилитой Traceroute для определения IP-адресов маршрутизаторов и топологии сети;

■ “protocol unreachable” может использоваться для полного сканирования хоста на предмет запущенных служб;

■ “port unreachable” может применяться для выявления активных хостов с открытыми UDP-портами;

■ “fragmentation needed but don' t-fragment bit set” позволяет определить значение MTU сетей с целью проведения атаки при использовании фрагментированного трафика.

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

Эхо-запросы без ответа

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

Иногда блокируют только входящие эхо-запросы, что позволяет диагностировать удаленные компьютеры и получать результаты из разрешенных к прохождению эхо-ответов. Однако хакеры тоже знают об этом, доказательством чему служат программы TFN и Loki, которые для доставки информации в основном используют эхо-ответы ICMP.

Отказ от возможностей Traceroute

Для определения маршрутизаторов, через которые проходит дейтаграмма на пути к получателю, в UNIX используется команда traceroute, а в Windows- tracert. Блокирование входящего ICMP-трафика не позволит запускать обе эти команды из вашей сети, так как для них требуется получить входящие ICMP-сообщения об истечении времени жизни пакета (“time exceeded in transit”).

Для команды tracert, используемой в системах под управлением Windows, требуется получение внешних эхо-запросов, поэтому удаленный пользователь не сможет применить эту команду для компьютеров в вашей сети. В свою очередь, UNIX-команда traceroute в качестве транспортного средства использует протокол UDP, поэтому блокирование входящего ICMP-трафика не повлияет на возможности удаленных пользователей применять ее для компьютеров вашей локальной сети.

Тишина в локальной сети

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

Неизвестное значение MTU

Как уже указывалось, по возможности хост-отправитель TCP-сообщений старается избежать фрагментации дейтаграмм на пути к адресату. Для этого определяется значение MTU всего пути - отправляется пробный пакет с установленным флагом DF. Этот пакет либо будет доставлен получателю, либо отправителю должно вернуться ICMP-сообщение “need to frag” с указанием наименьшего значения MTU.

Блокирование всех входящих ICMP-сообщений не дает работать этому механизму, что может привести к довольно серьезным проблемам. Хост-отправитель будет ожидать уведомления при необходимости фрагментации. Поскольку в результате блокирования он его не получит, будет продолжена отправка чрезмерно больших дейтаграмм с установленным флагом DF. Все они будут отброшены, но отправитель ничего об этом не узнает. Следовательно, пакет попадет адресату, только если его размер будет меньше значения MTU.

Поэтому, если принято решение о блокировании ICMP-трафика, то сделайте исключение для входящих ICMP-сообщений “host unreachable - need to frag”.

Резюме

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

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

В целях защиты блокируйте входящий ICMP-трафик, но делайте это разумно и избирательно. Закрыв путь хакерам, проверьте, не приводит ли установленное блокирование к каким-либо тяжелым последствиям.

Основы фрагментации | Обнаружение нарушений безопасности в сетях | Воздействия и реакции


Обнаружение нарушений безопасности в сетях



Новости за месяц

  • Июнь
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс