Хакеры атакуют: как уберечь DNS-сервер

  Ежедневно мы выходим в интернет, чтобы искать информацию, общаться, вести бизнес и так далее. Но мало кто задумывается о том, как осуществляется выход в сеть, и как мы попадаем на нужные страницы. Да и зачастую такие подробности знать не обязательно. Картина резко меняется, когда речь заходит об обеспечении безопасности. Для защиты от злоумышленников созданы различные средства ИБ, однако постоянно возникают новые уязвимости, а хакеры изобретают все новые способы атак. При организации безопасной веб-инфраструктуры обычно вспоминают о файловых, почтовых серверах и пр. Однако не менее важно защищать и системы доменных имен (Domain Name System, или DNS).

  DNS является распределенной системой, то есть представляет собой совокупность компьютеров, и предназначена для получения информации о доменах. Чаще всего пользуется для получения IP-адреса по имени хоста. Например, при вводе пользователем в адресную строку браузера адреса система DNS автоматически определит связанный с введенным именем IP и выдаст пользователю страницу по запрашиваемому адресу. Сейчас существует множество DNS-решений: BIND, Microsoft DNS Server, Open DNS и другие. Все они требуют защиты. Ведь, если хакер атакует DNS-сервер, то пользователи будут попадаться в ловушку, даже не подозревая об этом.

Чем опасны DNS-атаки

  Во–первых, в результате DNS-атак пользователь рискует не попасть на нужную страницу. При вводе адреса сайта атакованный DNS будет перенаправлять запрос на подставные страницы.

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

  Атаки на DNS – далеко не новая стратегия хакеров, однако только недавно борьба с этим видом угроз стала принимать глобальный характер. "В прошлом уже происходили атаки на DNS–сервера, приводящие к массовым сбоям. Так, например, в декабре прошлого года из-за подмены DNS–записи в течение часа для пользователей был недоступен известный всем сервис Twitter. Акция носила политический характер, и вместо интерфейса социальной сети на главной странице ресурса отображались предостережения иранских хакеров по поводу американской агрессии. Но подобные атаки относятся к локальным инцидентам и не так серьезны. Куда опаснее атаки на корневые DNS–сервера. В частности, широкую огласку получили атаки в октябре 2002 года, когда неизвестные пытались "задедосить" 10 из 13 DNS–серверов верхнего уровня, и в 2009 году, когда пытались нарушить работу как минимум двух корневых серверов", - рассказал Алексей Шевченко, руководитель направления инфраструктурных решений российского представительства ESET.

Виды атак

  Основной причиной такой подверженности DNS-систем угрозам является то, что они работают по протоколу UDP, более уязвимому, чем TCP.

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

  Второй способ атаки применяется удаленно, если нет доступа к трафику клиента. Для генерации ложного ответа необходимо выполнение нескольких пунктов. Во-первых, совпадение IP-адреса отправителя ответа с адресом DNS-сервера. Затем, совпадение имен, содержащихся в DNS–ответе и запросе. Кроме того, DNS–ответ должен посылаться на тот же порт, с которого был отправлен запрос. Ну и, наконец, в пакете DNS–ответа поле ID должно совпадать с ID в запросе.

  Первые два условия реализуются просто. А вот третий и четвертый пункт - сложнее. Обе задачи решаются подыскиванием нужный порта и ID методом перебора. Таким образом, у хакера есть все необходимое, чтобы атаковать жертву. Механизм этой атаки заключается в следующем. Жертва посылает на DNS–сервер запрос и переходит в режим ожидания ответа с сервера. Хакер, перехватив запрос, начинает посылать ложные ответные пакеты. В результате на компьютер клиента приходит шквал ложных ответов, из которых отсеиваются все, кроме одного, в котором совпали ID и порт. Получив нужный ответ, клиент начинает воспринимать подставной DNS–сервер как настоящий. Хакер же, в свою очередь, в ложном DNS ответе может поставить IP-адрес любого ресурса.

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

  Для атаки хакер посылает запрос, который заставляет сервер обращаться к другим узлам сети и ждать от них ответа. Отправив запрос, злоумышленник начинает атаковать DNS потоком ложных ответных пакетов. Напоминает ситуацию из предыдущего метода, но хакеру не надо подбирать порт, так как все сервера DNS "общаются" по выделенному 53 порту. Остается только подобрать ID. Когда сервер получит ложный ответный пакет с подходящим ID, он начнет воспринимать хакера как DNS и даст клиенту IP–адрес, посланный атакующим компьютером. Далее запрос будет занесен в кэш, и при последующих подобных запросах пользователи будут переходить на подставной IP.

Как защититься от атак

  Для обеспечения безопасности DNS планируется развертывание Domain Name System Security Extensions (DNSSEC). В основе протокола DNSSEC лежит метод цифровой подписи ответов на запросы. У администратора доменной зоны, поддерживающей данную технологию, есть закрытый ключ, который с помощью криптографических алгоритмов позволяет сгенерировать цифровую подпись. Клиенты же, в свою очередь, получают открытый ключ, соответствующий закрытому. Клиентский ключ дает возможность проверять валидность цифровой подписи. Возникает резонный вопрос: как получается так, что открытый ключ позволяет проверить подлинность подписи, но не дает возможности сгенерировать ее? Конечно, строгого теоретического запрета нет, но такая задача будет трудна для сколь угодно сложных ключей. Иначе говоря, раскрыть ключ можно, но при современном развитии технологий для этого потребуется недоступное на практике количество вычислительных ресурсов. Таким образом, видно, что теоретически защиту DNS взломать можно, впрочем, как и любую другую, но практически это пока не достижимо. Следует однако отметить, что DNSSEC усложняет работу взломщикам, но не дает 100% защиты, поскольку технологии злоумышленников тоже не стоят на месте. Тем не менее, по мнению экспертов, система защиты может помочь против таких вирусов, как, например, Kido, который в 2008 – 2009 годах устроил самую настоящую эпидемию.

  На данный момент система DNSSEC уже используется в Швейцарии и Болгарии. В планах распространить ее действие и на остальные зоны, в том числе и на .ru, .su и недавно появившуюся .рф. Ориентировочно это произойдет в конце 2011 года. В январе 2010 года началось развертывание нового протокола в 13 корневых серверах, и на сегодняшний день этот процесс завершен. Пока что процедура подписания корневых зон носит тестовый характер.

  К тому же, процесс внедрения DNSSEC требует немалых финансовых вложений. Поддержка этого протокола требует замены программного и аппаратного обеспечения как на серверной, так и на клиентской сторонах. По данным РБК daily, цифра, в которую обойдется переход на DNSSEC в России, может составить 100 млн долл.

DNSSEC и нагрузка на сеть

  Не стоит также забывать, что внедрение нового протокола увеличит объем передаваемых данных, причем почти в 2 раза. Так, например, при запросе списка серверов, обслуживающих зону .ru , в ответ придет не 257 байт, а 440. Разница ощутима. А если размеры пакета будут превышать 512 байт, то могут возникнуть проблемы с его приемом. Конечно, у этой проблемы есть решение. Если клиентский компьютер не в состоянии принимать пакеты больше 512 байт, сервер максимально сжимает их. Однако сжатие не безгранично, и если после него размер пакета все еще большой, то клиент автоматически переключится из транспортного протокола UDP в TCP, в котором нет подобных ограничений.

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

  "Создание цифровой подписи требует дополнительных вычислительных ресурсов DNS-сервера, подписывающего сообщение, и клиента, проверяющего подпись. Поскольку ЭЦП увеличивает объем информации, использование UDP-протокола становится рискованным с точки зрения надежности передачи данных, поскольку в некоторых сегментах сети фрагментирование больших пакетов может не поддерживаться, и DNSSEC на основе данного протокола просто не будет работать. Поэтому DNSSEC ориентирован на использование TCP, что может увеличить нагрузку на некоторые узлы, играющие роль шлюзов", – замечает Виталий Камлюк, ведущий антивирусный эксперт "Лаборатории Касперского".

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