Атаки из сети Интернет

Схема работы службы DNS

Теперь рассмотрим схему работы службы DNS с точки зрения конечного пользователя при обращении его на какой-либо Web сервер. Итак, что происходит, когда пользователь хочет зайти на сайт www.mydomain.com?

Компьютер обращается к DNS-серверу для того, чтобы тот преобразовал доменное имя mydomain.com в IP-адрес, на который он и будет обращаться. DNS-сервер, получив запрос, проверяет свой кеш на предмет нахождения в нем данной записи. Если она есть, то выдаёт компьютеру запрашиваемые данные, если нет, обращается к вышестоящим серверам. Чаще всего это бывает DNS-сервер провайдера, к которому подключена фирма. Кроме того, это могут быть корневые серверы DNS, и далее по цепочке.

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

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

• Ответ пришел с того же IP-адреса, на который посылался запрос.
• Ответ пришел на тот же порт, с которого посылался запрос.
• В ответе должно быть указано то же самое имя, что и в DNS-запросе.
• В заголовке DNS должно быть указано то же самое значение идентификатора запроса (ID), что и в самом запросе.

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

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

Конечно, для хакеров все не так радужно. Остается необходимость определить порт, с которого ваш сервер отправлял запрос, поле ID в запросе и придумать, как отправить UDP-пакет на ваш сервер от нужного IP-адреса (например, используя в качестве адреса отправителя IP-адрес сервера DNS вашего провайдера).

Однако решить эти задачи возможно.

Атаки типа IP-спуфинг указывают на то, что подделать адрес отправителя в ряде случаев оказывается возможным. К тому же UDP-протокол более подвержен этой атаке, нежели TCP, поскольку не имеет встроенных механизмов для предотвращения спуфинга.

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

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

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

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

***

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