Размер шрифта:
Межбуквенный интервал:
Изображения:
Отключить версию для слабовидящих close
Версия для людей с ограничением по зрению
Информационная безопасность

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

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

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

Самый простой способ противодействия атаке Камински подразумевает отправку запросов к DNS-серверам, случайным образом чередующие большие и маленькие буквы в имени домена. С точки зрения соответствия имени сайта и IP-адресов такие модификации ни на что не влияют, но, скажем, для домена example.com такой метод даёт 1024 варианта. Это резко уменьшает, но не сводит к нулю вероятность успеха атаки отравления кеша. Но наиболее надёжным, хотя и менее распространённым способом, является протокол DNSSec, расширение протокола DNS.

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

Корневая зона была подписана в 2010 году, и с тех пор ротация ни разу не проводилась. В октябре 2016 года, был создан новый ключ. Планировалось, что, начиная с 11 октября 2017 года, все ответы от корневых серверов должны были быть подписаны только ключом, выпущенным в 2017 году. На сайте ICANN был создан раздел, посвящённый ротации ключей. График соблюдался до конца сентября 2017 года, когда в распоряжении технических специалистов ICANN оказалась статистика распространения новых ключей по DNS-резолверам.

До апреля 2017 года возможности собрать статистику не было, пока не появилась спецификация — RFC 8145. Быстро реализованная в большинстве DNS-серверов, спецификация дала оценку в 5-10% резолверов, не получивших новые ключи - им, предположительно, могут соответствовать более 750 миллионов пользователей. При разработке процедуры ротации ключа предполагалось, что на процедуру может повлиять увеличенный размер ответа корневых серверов, но в итоге это проблем не вызвало. Изначально предполагалось, что процедуру получится провести в I квартале 2018 года, но потом было решено отложить её на более долгий срок.