Илья Медведовский - Атака на Internet Страница 20

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

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

Анализ подробно описанной здесь схемы удаленного DNS-поиска показывает, что если на запрос от DNS-сервера атакующий направит ложный DNS-ответ или (в случае шторма ложных ответов) будет вести их постоянную передачу, то в кэш-таблице сервера появится соответствующая запись с ложными сведениями, и в дальнейшем все хосты, обратившиеся к данному DNS-серверу, будут дезинформированы, а при адресации к хосту, маршрут к которому кракер решил изменить, связь с ним будет осуществляться через хост атакующего по схеме «ложный объект РВС». И, что хуже всего, с течением времени эта ложная информация, попавшая в кэш DNS-сервера, начнет распространяться на соседние DNS-серверы высших уровней, а следовательно, все больше хостов в Internet будут дезинформированы и атакованы.

Очевидно, что в том случае, когда взломщик не может перехватить DNS-запрос от DNS-сервера, для реализации атаки ему необходим шторм ложных DNS-ответов, направленный на DNS-сервер. При этом возникает следующая проблема, отличная от проблемы подбора портов в случае атаки на хост. Как уже отмечалось, DNS-сервер, посылая запрос на другой DNS-сервер, идентифицирует этот запрос двухбайтовым значением (ID). Это значение увеличивается на единицу с каждым передаваемым запросом. Атакующему узнать текущее значение идентификатора DNS-запроса не представляется возможным. Поэтому предложить что-либо, кроме перебора 216 вероятных значений ID, сложно. Зато исчезает проблема перебора портов, так как все DNS-запросы передаются DNS-сервером на порт 53.

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

Вспомним, например, скандал, произошедший 28 октября 1996 года вокруг одного из московских провайдеров Internet – компании РОСНЕТ, когда пользователи данного провайдера при обращении к обычному информационному WWW-серверу попадали, как было сказано в телевизионном репортаже, «на WWW-сервер сомнительного содержания». Этот инцидент вполне укладывается в только что описанную схему удаленной атаки на DNS-сервер. С одним исключением: вместо адреса хоста атакующего в кэш-таблицу DNS-сервера был занесен IP-адрес другого, не принадлежащего взломщику, хоста (порносайта).

Уже затем нам довелось ознакомиться с интервью, которое якобы дал кракер, осуществивший этот взлом. Из интервью следовало, что атака использовала некую известную «дыру» в WWW-сервере РОСНЕТ, что и позволило атакующему подменить одну ссылку другой. Осуществление воздействий такого типа является, по сути, тривиальным и не требует от взломщика практически никакой квалификации, за исключением изрядной доли усидчивости и навыков в применении известных технологий (подчеркнем: именно осуществление, а не нахождение этой «дыры»). По нашему глубокому убеждению, тот, кто найдет уязвимость, и тот, кто осуществит на ее базе взлом, скорее всего, будут разными лицами, так как обычно специалист, обнаруживший «дыру», не интересуется вопросами практического применения полученных знаний. (Р. Т. Моррис не стал исключением, просто его червь из-за ошибки в коде вышел из-под контроля, и пользователям Сети был нанесен определенный ущерб.) В завершение хотелось бы снова вернуться к службе DNS и сказать, что, как следует из вышеизложенного, использование в сети Internet службы удаленного поиска DNS позволяет атакующему организовать удаленную атаку на любой хост, пользующийся услугами данной службы, и может пробить серьезную брешь в безопасности этой, и так отнюдь не безопасной, глобальной сети. Как указывал С. М. Белловин (S. M. Bellovin) в ставшей почти классической работе [14]: «A combined attack on the domain system and the routing mechanisms can be catastrophic» («Комбинированная атака на доменную систему и механизмы маршрутизации может привести к катастрофическим последствиям»).

Навязывание хосту ложного маршрута с использованием протокола ICMP

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

Рис. 4.9. Таблица маршрутизации хоста

В каждой строке этой таблицы содержится описание соответствующего маршрута, которое включает IP-адрес конечной точки пути (сетевой адрес), IP-адрес соответствующего ближайшего маршрутизатора (адрес маршрутизатора), а также ряд других параметров, характеризующих этот путь. Обычно в системе существует так называемый маршрут по умолчанию (поле «сетевой адрес» содержит значение 0.0.0.0, заданное по умолчанию, а поле «адрес маршрутизатора» – IP-адрес маршрутизатора): все пакеты, посылаемые на IP-адрес вне пределов данной подсети, будут направляться по этому пути, то есть на маршрутизатор. IP-адресация, как адресация на сетевом уровне, была задумана именно для межсегментной передачи данных из одной точки глобальной сети в другую. Для обращения на канальном уровне используются аппаратные адреса сетевых карт. Если бы Сеть представляла собой всего один сегмент, то дополнительной IP-адресации не потребовалось бы, так как аппаратных адресов сетевых адаптеров было бы вполне достаточно для непосредственной пересылки пакетов. Сегодня Internet представляет собой совокупность сегментов, соединенных через маршрутизаторы, и в Сети мы вынуждены использовать систему двойной адресации (по аппаратным и сетевым адресам). Поэтому, когда пакет направляется в другой сегмент Сети, в заголовке сетевого уровня указывается IP-адрес назначения, а в заголовке канального уровня – Ethernet-адрес ближайшего маршрутизатора.

Немного о ICMP

Как известно, в сети Internet существует управляющий протокол ICMP (Internet Control Message Protocol), одной из функций которого является удаленное управление таблицей маршрутизации на хостах внутри сегмента Сети. Динамическое удаленное управление маршрутизацией изначально задумывалось для предотвращения возможной передачи сообщений по неоптимальному маршруту, а также для повышения отказоустойчивости Сети в целом. Предполагалось, что сетевой сегмент может быть подключен к Internet не через один (как это обычно происходит), а через несколько маршрутизаторов. В этом случае адресоваться во внешнюю сеть можно через любой из ближайших узлов. Это довольно удобно как с точки зрения оптимальности маршрута (например, к хосту www.example.one кратчайший маршрут проходит через первый маршрутизатор, а к хосту www.example.two – через второй маршрутизатор), так и с точки зрения повышения надежности работы Сети: при выходе из строя одного из маршрутизаторов связь с внешним миром возможна через другой маршрутизатор. В обоих случаях – как при изменении оптимального маршрута, так и при выходе из строя маршрутизатора – необходимо изменение таблицы маршрутизации в памяти сетевой операционной системы. Одно из назначений протокола ICMP состоит именно в динамическом изменении таблицы маршрутизации оконечных сетевых систем.