DNS-атаки: защита бизнеса или анализ рисков DNS
DNS-атаки - старая, но всё ещё актуальная область хакерских исследований, представляющая во многих случаях серьёзную опасность сегодня практически для любого бизнеса. Учитывая, что UDP-протокол DNS почти не изменился с начала 80-ых, и разрабатывался он без какого-либо учёта безопасности, а современные IT-средства и умы хакеров значительно улучшились, проблема становится ещё актуальнее. В особенности, актуальной в контексте данной IT-угрозы становится защита бизнеса. Существующие в современном мире виды DNS-атак могут привести не только к воровству финансовой информации (как частного лица, так и компании) или коммерческой тайны, а и к воровству самих финансов, как явно и буквально (например, через подмену сетевых пакетов в системе ДБО), так и косвенно (коммерческая тайна и конкуренты). Не брать в расчёт данный тип атак, значит, совершить серьёзную ошибку в стратегическом планировании бизнеса компании.
В предыдущей статье мы рассмотрели все основные ныне существующие типы DNS-атак и угрозы, которые они в себе несут. В данной статье проведём анализ возможных рисков и способы защиты от DNS-атак.
Анализ рисков DNS
Исходя из множества видов DNS-атак (рассмотренных в указанной выше статье), можно провести последовательный анализ рисков, связанных с угрозами протокола DNS.
Итак, таблица анализа рисков:
|
№ |
Описание угрозы |
Вероятность (сложность) реализации |
Ущерб |
|
1 |
Несоответствие законодательству по ПДн для новых ИСПДн. (п.8.10 (требование ЗИС.15) Приказа ФСТЭК №21) |
Высокая |
Высокий. Для новых ИСПДн: признание ИС несоответствующей; приостановление работы ИС. |
|
2 |
Для случая нахождения в сетевом сегменте пользователя и/или DNS-сервера (и соответственно, доступа к его трафику): подмена DNS-сервера собственным ложным сервером с последующей отправкой ложных DNS-ответов. Пример реализации: подмена любого web-сервиса организации с парольной аутентификацией ложным, чтение паролей с последующим перенаправлением на настоящий web-сервис и отправкой пользователям получаемых ответов (незаметно для пользователя и эффективно для злоумышленника). Все пароли будут украдены, любые запросы к сервису можно подменять на ложные. |
Средне-высокая (внутри сегмента сети пользователя) |
Очень высокий. Подмена всех сетевых ресурсов, имеющих dns-имена, собственными, что влечёт получение доступа к информации пользователя (в том числе к его паролям). Перехват всего трафика пользователя. Подмена любых сетевых запросов. |
|
3 |
Для случая нахождения в произвольной точке сети (без прямого доступа к трафику жертвы): отправка шквала ложных DNS-ответов с подменой IP DNS-сервера и подбором порта и ID пользователя (в любой точке сети). Далее, подъём собственного DNS-сервера и дубликата сервиса аналогично риску п.2. |
Средняя |
Аналогично п.2. |
|
4 |
Для случая нахождения в любой точке сети (возможно, без доступа к самой жертве и при отсутствии собственного DNS в организации): отправка отсутствующего в кэше DNS-сервера запроса и последующий шквал ложных DNS-ответов от имени (IP) вышестоящего (возможно, корневого) DNS-сервера на нижестоящий (DNS-сервер жертвы), что влечёт изменение кэш-таблицы нижестоящего DNS и последующая стратегия подмены сервисов аналогичная рискам пп.2-3. |
Средне-высокая (работает в случае dns-запроса, отсутствующего в текущем кэше DNS; условие нахождения внутри сети организации отсутствует) |
Аналогично п.2 |
|
5 |
Для произвольного случая (расположение злоумышленника неважно; атака применима к любым хостам организации, доступных из внешней сети): атака посредством отражённых DNS-ответов. Злоумышленник отправляет серию DNS-запросов с подменённым IP отправителя (на IP жертвы) множеству DNS-серверов. В запросе содержатся имена с коэффициентом удлинения DNS-ответа от 10 и выше (до 100). В итоге, происходит массированная DDoS-атака. |
Средне-высокая (не использует ресурсы интрасети; не требует нахождения внутри сети организации) |
Высокий. Высокий ущерб нарушения доступности произвольного хоста, смотрящего во внешнюю сеть. |
|
6 |
Для случая наличия собственного DNS-сервера в организации: атаки типа DDoS на DNS-сервер: простой DNS-флуд; рекурсивная DNS-атака; Garbage-атака. В итоге: полное падение DNS-сервера. |
Средне-высокая (в случае наличия собственного DNS-сервера; не требует нахождения внутри сети организации) |
Средний / высокий. Высокий ущерб нарушения работы DNS-сервера организации (несложно восстановить). В случае отсутствия резервного DNS нарушается работа всей сети. |
Пункты 2-5 основаны на лёгком формировании DNS-UDP-пакета с возможностью легко вставить в пакет произвольные данные по IP, ID и т.д. Более подробное описание угроз пунктов 2-6 содержится в предыдущей статье DNS-атаки: полный обзор по схемам атак.
Как видно из таблицы, риски в данной области имеются весьма серьёзные и обрабатывать их надо. Перейдём к описанию методов борьбы с угрозами DNS-атак и оценке эффективности / превентивности данных методов.
Методы защиты от DNS-атак
Методы защиты сводятся к двум основным направлениям: правильной настройка DNS-сервера и к использованию протокола DNSSec. Опишем оба варианта.
Итак, необходимые (но не достаточные) настрройки DNS-сервера:
- Игнорирование или уменьшение степени доверия к любым DNS-ответам, явно не относящихся к отправляемым запросам (параметры BIND8/9/10 позволяют это сделать). Снижает риски 3, 4 (частично - 6).
- Использование случайных портов для отправки/получения запроса. Существенно снижает риски 3, 4.
- Запрет обработки рекурсивных запросов, поступающих не от доверенных клиентов (не из инстрасети / её доверенной части).
Что же касается протокола DNSSec, то это достаточно мощный инструмент, суть которого сводится к использованию целой инфраструктуры открытых ключей (PKI) для проведения аутентификации любых доменных сообщений с построением цепочки доверия. Все запроса и ответы подписаны своей ЭЦП, подлинность которой обеспечивает соответствующий сертификат УЦ. В контексте такой меры риски 1, 2, 3, 4 (в случае использования DNSSec на вышестоящих серверах) и - частично - риск 6 становятся неактуальны. Одним махом. Остаётся риск 5, но его преодолеть силами одной организации нереально никак. Он может быть уменьше только через повсеместное использование протокола DNSSec.
Становится вопрос превентивности, т.е. выгодности внедрения нового протокола для бизнеса. Надо сказать, что сам протокол является открытым, бесплатным и поддерживается уже почти всеми современными DNS-серверами (включая BIND) и клиентскими ОС (включая Windows 7 и Windows 2008 Server).
Итак, проблемы внедрения DNSSec:
- Протокол TCP/IP должен поддерживать новый DNS Resolver, умеющий работать с DNSSec.
- Возрастание нагрузки на сеть: траффик от подписанных ЭЦП запросов возрастает в 6-7 раз.
- Возрастание нагрузки на процессор DNS-сервера (генерация и проверка ЭЦП требует множество ресурсов), так что может потребоваться замена DNS-серверов на более мощные (раза в ~2-3).
- Увеличение требований по дисковому пространству серверов, т.к. данные подписанные данные об адресации занимают ощутимо больше места.
Как видно из представленного списка, проблемы внедрения DNSSec связаны с верной настройкой ПО (что решается без труда) и возросшими требованиями по аппаратным ресурсам DNS-серверов, а также интернет-канала (хотя это во многом зависит от величины организации).
Подводя итоги, можно сказать, что внедрение протокола DNSSec выглядит оправданным для организаций среднего и крупного бизнеса с высокой критичностью доступа в интернет и/или использованием критичных сетевых сервисов. Для организаций малого бизнеса, не использующей облачной архитектуры или других подобных сервисов использование такого протокола зависит от конкретной ситуации и требует индивидуального рассмотрения.
A.S.
