INFO.Z-PDF.RU
БИБЛИОТЕКА  БЕСПЛАТНЫХ  МАТЕРИАЛОВ - Интернет документы
 

«ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ КЕМЕРОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Институт фундаментальных наук Кафедра ...»

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

КЕМЕРОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Институт фундаментальных наук

Кафедра ЮНЕСКО по информационным вычислительным технологиям 

КУРСОВАЯ РАБОТА

«Защита DNS-серверов от сетевых атак»

студентки 3 курса, М-145 группы 

Черной Анны Александровны

Специальность 02.03.03 – «Математическое обеспечение

и администрирование информационных систем»

 

Научный руководитель:

Канд. физ.-мат. наук, доцент

С. Н. Карабцев_____________________ 

 

Работа защищена с оценкой

«___» (_________________)

“____” _____________2017г.

 

Зав. кафедрой ЮНЕСКО по ИВТ,

д.-р физ.-мат.наук, профессор

________________ Ю.Н. Захаров 

Кемерово 2017

Оглавление

TOC \o "1-3" \h \z \u Введение PAGEREF _Toc486262284 \h 4Глава 1. Основные понятия PAGEREF _Toc486262285 \h 5Домен PAGEREF _Toc486262286 \h 5Поддомен PAGEREF _Toc486262287 \h 6Ресурсная запись PAGEREF _Toc486262288 \h 6Зона PAGEREF _Toc486262289 \h 6Делегирование PAGEREF _Toc486262290 \h 7DNS-сервер PAGEREF _Toc486262291 \h 7DNS-клиент PAGEREF _Toc486262292 \h 8Авторитетность PAGEREF _Toc486262293 \h 8DNS-запрос PAGEREF _Toc486262294 \h 8Глава 2.



Виды DNS атак. PAGEREF _Toc486262295 \h 81.Ложный DNS-сервер PAGEREF _Toc486262296 \h 92. Простой DNS-флуд / Атака посредством отраженных DNS-запросов PAGEREF _Toc486262297 \h 103. Атака с помощью рекурсивных DNS-запросов. PAGEREF _Toc486262298 \h 124. Атаки типа Garbage. PAGEREF _Toc486262299 \h 13Глава 3.Защита DNS-сервера. PAGEREF _Toc486262300 \h 14Протокол DNSSEC PAGEREF _Toc486262301 \h 14Описание PAGEREF _Toc486262302 \h 14Принцип работы PAGEREF _Toc486262303 \h 15Подпись корневой зоны PAGEREF _Toc486262304 \h 18Проблемы внедрения и недостатки PAGEREF _Toc486262305 \h 18Глава 4. Практическая часть PAGEREF _Toc486262306 \h 19Цели PAGEREF _Toc486262307 \h 20Используемое ПО PAGEREF _Toc486262308 \h 20Ход работы PAGEREF _Toc486262309 \h 20Развертывание BIND9(DNS-сервера) PAGEREF _Toc486262310 \h 20Настройка прямой зоны PAGEREF _Toc486262311 \h 22Настройка обратной зоны PAGEREF _Toc486262312 \h 25Атака PAGEREF _Toc486262313 \h 27Защита PAGEREF _Toc486262314 \h 28Заключение PAGEREF _Toc486262315 \h 31Список литературы PAGEREF _Toc486262316 \h 32

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

Зачем специалисту необходимы знания о методах атак на протокол DNS?

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





Специалист должен знать с чем имеет дело, чтобы успешно с этим бороться, а лучше и вовсе минимизировать вероятность появления вредоносных атак.

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

Глава 1. Основные понятияСетевая атака - действие, целью которого является захват контроля (повышение прав) над удалённой/локальной вычислительной системой, либо её дестабилизация, либо отказ в обслуживании, а также получение данных пользователей пользующихся этой удалённой/локальной вычислительной системой.

DNS (англ. Domain Name System — система доменных имён) — компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене.

Располагается на 7 уровне сетевой модели OSI. Семейство: TCP/IP. Порты: 53/TCP, 53/UDP.

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

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

Домен (англ. domain — область) — узел в дереве имён, вместе со всеми подчинёнными ему узлами (если таковые имеются), то есть именованная ветвь или поддерево в дереве имен. Структура доменного имени отражает порядок следования узлов в иерархии; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости): вверху находится корневой домен (не имеющий идентификатора), ниже идут домены первого уровня (доменные зоны), затем — домены второго уровня, третьего и т. д. (например, для адреса ru.wikipedia.org. домен первого уровня — org, второго wikipedia, третьего ru). На практике точку перед корневым доменом часто опускают ("ru.wikipedia.org" вместо "ru.wikipedia.org."), но она бывает важна в случаях разделения между относительными доменами и FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена).

Поддомен (англ. subdomain) — подчинённый домен (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения. Например, если у вас есть домен вида mydomain.ru, вы можете создать для него различные поддомены вида mysite1.mydomain.ru, mysite2.mydomain.ru и т. д.

Ресурсная запись — единица хранения и передачи информации в DNS. Каждая ресурсная запись имеет имя (то есть привязана к определенному Доменному имени, узлу в дереве имен), тип и поле данных, формат и содержание которого зависит от типа.

Зона — часть дерева доменных имен (включая ресурсные записи), размещаемая как единое целое на некотором сервере доменных имен (DNS-сервере), а чаще — одновременно на нескольких серверах. Целью выделения части дерева в отдельную зону является передача ответственности за соответствующий домен другому лицу или организации. Это называется делегированием. Как связная часть дерева, зона внутри тоже представляет собой дерево. Если рассматривать пространство имен DNS как структуру из зон, а не отдельных узлов/имен, тоже получается дерево; оправданно говорить о родительских и дочерних зонах, о старших и подчиненных. На практике большинство зон 0-го и 1-го уровня ('.', ru, com, …) состоят из единственного узла, которому непосредственно подчиняются дочерние зоны. В больших корпоративных доменах (2-го и более уровней) иногда встречается образование дополнительных подчиненных уровней без выделения их в дочерние зоны.

Делегирование — операция передачи ответственности за часть дерева доменных имен другому лицу или организации. За счет делегирования в DNS обеспечивается распределенность администрирования и хранения. Технически делегирование выражается в выделении этой части дерева в отдельную зону, и размещении этой зоны на DNS-сервере, управляемой этим лицом или организацией. При этом в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны.

DNS-сервер — специализированное ПО для обслуживания DNS, а также компьютер, на котором это ПО выполняется. DNS-сервер может быть ответственным за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.

DNS-сервера бывают рекурсивные и нерекурсивные.

Рекурсивные всегда возвращают клиенту ответ — они самостоятельно отслеживают отсылки к другим DNS-серверам и опрашивают их. Кэшируют все промежуточные ответы, и при последующих запросах ответы будут возвращаться намного быстрее. Удобно использовать на низких уровнях (локальная сеть)

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

DNS-клиент — специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента.

Авторитетность (англ. authoritative) — признак размещения зоны на DNS-сервере. Ответы DNS-сервера могут быть двух типов: авторитетные (когда сервер заявляет, что сам отвечает за зону) и неавторитетные (англ. Non-authoritative), когда сервер обрабатывает запрос, и возвращает ответ других серверов. В некоторых случаях вместо передачи запроса дальше DNS-сервер может вернуть уже известное ему (по запросам ранее) значение (режим кеширования).

DNS-запрос (англ. DNS query) — запрос от клиента (или сервера) серверу.

Глава 2. Виды DNS атак.

Атаки на DNS можно условно разделить на две категории.

Первая категория - это атаки на уязвимости в DNS-серверах. С этим подвидом атак связаны следующие опасности:

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

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

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

Ложный DNS-серверЦели и угрозы: подмена доверенных объектов сети; перехват практически любого трафика жертвы; подмена сетевых запросов/ответов.

Схема реализации атаки в случае, если есть доступ к трафику жертвы (случай на картинке):

Атакующий ждёт DNS-запроса от жертвы на хосте 1 (атакующий находится либо на хосте нарушителя 1, либо на хосте нарушителя 2; но может быть и где-либо ещё, где есть доступ к трафику хоста 1 (жертвы)).

После передачи хостом 1 DNS-запроса, атакующий принимает запрос, в котором запоминает ID и порт. Далее, атакующий отправляет ложный DNS-ответ, в котором подменяет поле IP-адрес DNS-сервера на свой IP, делая свой компьютер для жертвы целевым DNS-сервером.

Хост 1 принимает ложный DNS-ответ, принимает IP-адрес хакера за подлинный DNS-сервер и отправляет все последующие запросы ему.

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

2. Простой DNS-флуд / Атака посредством отраженных DNS-запросов Цели и угрозы: переполнение сервера запросами; потребление всех ресурсов сервера; выведение DNS-сервера - жертвы - из строя.

Схема реализации атаки простой DNS-флуд:

Злоумышленник отправляет множественные DNS-запросы на атакуемый DNS-сервер, переполняя сервер запросами и тем самым потребляя его ресурсы.

Стандартный ПК может сгенерировать 1000 DNS-запросов в секунду, тогда как обычный DNS-сервер может обработать только 10000 DNS-запросов в секунду. Следовательно, для того, чтобы вывести из строя DNS-сервер, потребуется всего 10 компьютеров.

Такой метод атаки очень популярен среди злоумышленников, так как сам по себе прост в исполнении и при этом позволяет скрыть личность злоумышленника.

Схема реализации атаки посредством отраженных DNS-запросов:

Злоумышленник отправляет DNS-запрос на один или несколько сторонних DNS-серверов, которые не являются реальными объектами нападения. Злоумышленник изменяют IP-адрес источника DNS-запроса на IP-адрес целевого сервера, который и является целью атаки, тогда ответ сторонних серверов будет отправлен на сервер, который является целью нападения.

В процессе атаки используется эффект усиления, при котором ответ на DNS-запрос в 3-10 раз больше, чем сам DNS-запрос. В результате на атакуемый сервер поступает гораздо больше трафика по сравнению с небольшим количеством запросов, сгенерированных злоумышленником. Успех атаки демонстрирует, что организации не требуется владеть DNS-сервером, чтобы стать объектом DNS-атаки.

Степень анонимности при такой атаке возрастает с увеличением ее размаха. Помимо изменения SRC IP (как при простом DNS-флуде), атака сама по себе производится не напрямую - запросы на атакуемый сервер отправляются сторонним сервером.

3. Атака с помощью рекурсивных DNS-запросов.  Цели и угрозы: выведение DNS-сервера - жертвы - из строя.

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

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

4. Атаки типа Garbage.  

Цели и угрозы: выведение DNS-сервера - жертвы - из строя.

Атака типа Garbage-DNS основывается на постоянно открытом 53 порту (стандартному порту DNS, иногда используется 80-ый). Схема атаки сводится к отправке злоумышленником (с множества хостов) больших (свыше 1500 байт) сетевых пакетов (не обязательно DNS). Таким образом,  всё сводится к обычному DDoS, но на DNS-порт. Преимущество над обычным DDoS состоит в том, что 53-й порт (DNS-порт) всегда открыт в любых организациях, ибо нужен для работоспособности DNS-системы.

Глава 3.Защита DNS-сервера.

Протокол DNSSECDNSSEC (англ. Domain Name System Security Extensions) — набор расширений IETF протокола DNS, позволяющих минимизировать атаки, связанные с подменой DNS-адреса при разрешении доменных имён. Он направлен на предоставление DNS-клиентам (англ. термин resolver) аутентичных ответов на DNS-запросы (или аутентичную информацию о факте отсутствия данных) и обеспечение их целостности. При этом используется криптография с открытым ключом. Не обеспечивается доступность данных и конфиденциальность запросов. Обеспечение безопасности DNS критически важно для интернет-безопасности в целом.

ОписаниеИзначально Domain Name System (DNS) разрабатывался не в целях безопасности, а для создания масштабируемых распределённых систем. Со временем система DNS становится всё более уязвимой. Злоумышленники без труда перенаправляют запросы пользователей по символьному имени на подставные серверы и таким образом получают доступ к паролям, номерам кредитных карт и другой конфиденциальной информации. Сами пользователи ничего не могут с этим поделать, так как в большинстве случаев даже не подозревают о том, что запрос был перенаправлен — запись в строке браузера и сам сайт в точности такие, какими их и ожидает увидеть пользователь. DNSSEC является попыткой обеспечения безопасности при одновременной обратной совместимости.

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

DNSSEC не шифрует данные и не изменяет управление ими, являясь совместимой с ранними версиями текущей системы DNS и приложений. DNSSEC может удостоверить и такую информацию, как криптографические сертификаты общего назначения, хранящиеся в CERT record DNS. RFC 4398 описывает, как распределить эти сертификаты, в том числе по электронной почте, что позволяет использовать DNSSEC в качестве глобального распределённого хранилища сертификатов ключей подписи.

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

Принцип работыПроверка подлинности данных в DNSSEC

Принцип работы DNSSEC основан на использовании цифровых подписей. У администратора имеются записи о соответствии имени домена и IP-адреса. DNSSEC ставит каждой из них в строгое соответствие специальную, строго определённую последовательность символов, которая представляет собой цифровую подпись. Главная особенность цифровой подписи в том, что есть открытые, публично доступные методы проверки достоверности подписи, а вот генерирование подписи для произвольных данных требует наличия в распоряжении подписывающего секретного ключа. Поэтому проверить подпись может каждый участник системы, но подписать новые или изменённые данные на практике может только тот, у кого есть секретный ключ.

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

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

Допустим, пользователь обращается к сайту wikipedia.org. Происходит следующее:

Пользователь запрашивает доменное имя у резолвера;

Резолвер запрашивает wikipedia.org у DNS-сервера (допустим, в кэше локальных серверов информации о домене не нашлось и запрос дошёл до сервера провайдера;

При отсутствии информации в кэше серверов провайдера запрос перенаправляется на корневой сервер, также выставляется бит DO, информирующий о том, что используется DNSSEC;

Корневой сервер сообщает, что за зону org отвечает сервер a.b.c.net. При этом сервер отправляет набор NS-записей для зоны org, дайджесты KSK зоны org (записи DS) и подпись (запись типа RRSIG) записей NS и DS;

Резолвер проводит валидацию полученного ZSK путём проверки соответствия подписи, выполненной ключом KSK корневой зоны. Затем резолвер проверяет цифровую подпись записей DS корневой зоны, содержащуюся в записи RRSIG. Если и тут все верно, то сервер доверяет полученным дайджестам и проверяет с их помощью подпись записи DNSKEY уровня ниже — зоны org;

Теперь, после получения адреса сервера, ответственного за зону org (сервера a.b.c.net), резолвер переправляет ему тот же запрос;

Сервер a.b.c.net сообщает о том, что сервер, ответственный за зону wikipedia.org, имеет адрес d.org. Также он отправляет подписанные с помощью закрытого KSK зоны org набор ключей подписи (ZSK) зоны org и подписанный с помощью ZSK зоны org дайджест KSK зоны wikipedia.org;

Резолвер проводит сравнение полученного от корневого сервера хеша с тем, что он посчитал самостоятельно из KSK зоны org, полученного от сервера a.b.c.net, и в случае совпадения начинает доверять этому KSK. После этого резолвер проверяет подписи ключей из зоны org и начинает доверять ZSK зоны org. Затем резолвер проверяет KSK зоны wikipedia.org. После всех этих проверок у резолвера есть дайджест (DS) KSK зоны wikipedia.org и адрес сервера d.org, где хранится информация о зоне wikipedia.org;

Наконец резолвер обращается на сервер d.org за сайтом wikipedia.org, и при этом выставляет бит о том, что использует DNSSEC;

Сервер d.org понимает, что зона wikipedia.org находится на нём самом, и отправляет резолверу ответ, содержащий подписанный с помощью KSK зоны wikipedia.org набор ключей подписи (ZSK) зоны wikipedia.org и подписанный с помощью ZSK зоны wikipedia.org адрес сайта wikipedia.org;

Также, как в пункте 7 резолвер проверяет KSK зоны wikipedia.org, ZSK зоны wikipedia.org и адрес сайта wikipedia.org;

При удачной проверке в пункте 10 резолвер возвращает пользователю ответ, содержащий в себе адрес сайта wikipedia.org и подтверждение, что ответ верифицирован (выставленный бит AD).

При невозможности что-то провалидировать резолвер вернет ошибку servfail.

Таким образом образующаяся цепочка доверия сводится к корневому домену и ключу корневой зоны.

Delegation of Signing (DS)-запись содержит хэш доменного имени наследника и его ключа KSK. Запись DNSKEY содержит публичную часть ключа и его идентификаторы (ID, тип и используемая хэш-функция).

KSK (Key Signing key) означает ключ подписи ключа (ключ долговременного пользования), а ZSK (Zone Signing Key) означает ключ подписи зоны (ключ кратковременного пользования). С помощью KSK верифицируется ZSK, которым подписывается корневая зона. ZSK корневой зоны создаёт компания VeriSign, которая технически отвечает за распространение корневой зоны DNS. По принятой ICANN процедуре ZSK корневой зоны обновляется четырежды в год.

Подпись корневой зоныДля полноценной валидации всех данных, передаваемых с помощью DNSSEC, нужна цепочка доверия, идущая от корневой зоны (.) DNS. Внедрение подписанной корректным образом корневой зоны на все корневые серверы DNS могло вызвать крах современного Интернета, поэтому IETF вместе с ICANN была разработана постепенная процедура внедрения подписанной корневой зоны и механизма распространения ключей. Процедура затянулась более, чем на 8 месяцев и включала в себя пошаговое внедрение на серверы DNS сначала корневой зоны, подписанной недействительным ключом электронной подписи. Этот шаг был необходим для того, чтобы обеспечить тестирование серверов под нагрузкой, сохранить обратную совместимость со старым программным обеспечением и оставить возможность отката к предыдущей конфигурации.

Проблемы внедрения и недостаткиВнедрение DNSSEC сильно задержалось по таким причинам, как:

Разработка обратно совместимого стандарта, который можно масштабировать до размера интернета;

Разногласия между ключевыми игроками по поводу того, кто должен владеть доменами верхнего уровня (.com,.net);

DNS серверы и клиенты должны поддерживать DNSSEC;

Обновленные DNS-резолверы, умеющие работать с DNSSEC, должны использовать TCP;

Каждый клиент должен получить хотя бы один доверенный открытый ключ до того момента, как он начнет использовать DNSSEC;

Возрастание нагрузки на сеть из-за серьёзно (в 6-7 раз) возросшего трафика от запросов;

Возрастание нагрузки на процессор сервера из-за потребности генерации и проверки подписей, так что может потребоваться замена некоторых недостаточно мощных DNS-серверов;

Увеличение требований для хранилищ информации об адресации, так как подписанные данные занимают гораздо больше места;

Нужно создавать, тестировать и дорабатывать программное обеспечение как серверной, так и клиентской части, что требует времени и испытаний в масштабах всего интернета;

Stub-резолверы не защищены от отравления кеша - валидация происходит на стороне рекурсивного сервера, клиент получает только ответ с выставленным битом AD;Резко возросла опасность атаки DNS Amplification.

Глава 4. Практическая частьВ практической части мы рассмотрим способ создания атаки подмены DNS-ответа и меры защиты от нее.

В локальной сети находится три компьютера: DNS-сервер с ip-адресом 192.168.1.1, компьютер жертвы c ip-адресом 192.168.1.2 и соответственно с DNS-сервером 192.168.1.1, компьютер злоумышленника с ip-адресом 192.168.1.3

ЦелиДля злоумышленника:

Перехватить данные

Перехватить ответные пакеты от DNS-сервера

Подмена ip-адреса ресурса

Для сервера:

Развернуть защитный протокол DNSSEC

Предотвратить угрозу пользователям

Используемое ПОVirtualBox (Oracle VM VirtualBox) — программный продукт виртуализации для операционных систем Microsoft Windows, Linux, FreeBSD, Mac OS X, Solaris/OpenSolaris, ReactOS, DOS и других.

BIND9 (Berkeley Internet Name Domain)-DNS-сервер входящий в состав любого дистрибутива UNIX (в нашем случае Ubuntu 14.04)

Netwox 5.39 -многофункциональная программа, в нашем случае используем как снифер, спуфер, перехватчик пакетов.

WinPcap - это популярный инструмент, работающий в среде Microsoft Windows, позволяющий приложениям захватывать и передавать сетевые пакеты в обход стека протоколов. Имеет такие дополнительные функции, как фильтрацию пакетов на уровне ядра, движок статистики сети и поддержку удаленного захвата пакетов.(необходим для работы Netwox)

Ход работыРазвертывание BIND9(DNS-сервера)

1. Скачиваем BIND9 при помощи команды sudo apt-get install bind9.

2. Прописываем имя DNS-сервера, и его IP в файле /etc/hosts (команда sudo nano /etc/hosts). (рисунок 1)

Рисунок 1

Переходим в директорию BIND (команда cd /etc/bind).

3. Добавим в файл named.conf.local файлы конфигураций прямой и обратных зон (команда sudo nano named.conf.local).

Рисунок 2

Настройка прямой зоны4. Создадим файл ресурсной записи lanlinux.ru.zone (т.к именно его мы указали в named.conf.local) (sudo nano lanlinux.ru.zone(команда nano-обычный редактор, однако если указанного файла не существует он его автоматически создаст)

И прописываем прямую зону как показано на рисунке 3

Рисунок 3

Запись ресурса состоит из следующих полей:

имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись, либо IP адрес. При отсутствии данного поля, запись ресурса наследуется от предыдущей записи.

Time To Live (TTL) — дословно «время жизни» записи, время хранения записи в кэше DNS (после указанного времени запись удаляется), данное поле может не указываться в индивидуальных записях ресурсов, но тогда оно должно быть указано в начале файла зоны и будет наследоваться всеми записями.

класс (CLASS) — определяет тип сети, (в 99,99% случаях используется IN (что обозначает — Internet). Данное поле было создано из предположения, что DNS может работать и в других типах сетей, кроме TCP/IP)тип (TYPE) — тип записи синтаксис и назначение записи

данные (DATA) — различная информация, формат и синтаксис которой определяется типом.

При этом, возможно использовать следующие символы:

;   -  Вводит комментарий

#  -  Также вводит комментарии (только в версии BIND 4.9)

@  — Имя текущего домена

( )    — Позволяют данным занимать несколько строк

— Метасимвол (только в поле имя)

A — (address record/запись адреса) отображают имя хоста (доменное имя) на адрес IPv4. Для каждого сетевого интерфейса машины должна быть сделана одна A-запись.

AAAA (IPv6 address record) аналогична записи A, но для IPv6.

CNAME (canonical name record/каноническая запись имени (псевдоним)) — отображает алиас на реальное имя (для перенаправления на другое имя).

MX (mail exchange) — указывает хосты для доставки почты, адресованной домену. При этом поле NAME указывает домен назначения, поля TTL, CLASS — стандартное значение, поле TYPE принимает значение MX, а поле DATA указывает приоритет и через пробел - доменное имя хоста, ответственного за прием почты.

NS (name server/сервер имён) указывает на DNS-сервер, обслуживающий данный домен. Вернее будет сказать — указывают сервера, на которые делегирован данный домен. Если записи NS относятся к серверам имен для текущей зоны, доменная система имен их практически не использует. Они просто поясняют, как организована зона и какие машины играют ключевую роль в обеспечении сервиса имен.

PTR (pointer) — отображает IP-адрес в доменное имя (о данном типе записи поговорим ниже в разделе обратного преобразования имен).

SOA (Start of Authority/начальная запись зоны) — описывает основные/начальные настройки зоны, можно сказать, определяет зону ответственности данного сервера. Для каждой зоны должна существовать только одна запись SOA и она должна быть первая. Поле Name содержит имя домена/зоны, поля TTL, CLASS — стандартное значение, поле TYPE принимает значение SOA, а поле DATA состоит из нескольких значений, разделенных пробелами: имя главного DNS (Primary Name Server), адрес администратора зоны, далее в скобках — серийный номер файла зоны (Serial number). При каждом внесении изменений в файл зоны данное значение необходимо увеличивать, это указывает вторичным серверам, что зона изменена, и что им необходимо обновить у себя зону. Далее — значения таймеров (Refresh — указывает, как часто вторичные серверы должны опрашивать первичный, чтобы узнать, не увеличился ли серийный номер зоны, Retry — время ожидания после неудачной попытки опроса, Expire — максимальное время, в течение которого вторичный сервер может использовать информацию о полученной зоне, Minimum TTL — минимальное время, в течение которого данные остаются в кэше вторичного сервера). SRV (server selection) — указывают на сервера, обеспечивающие работу тех или иных служб в данном домене (например  Jabber и Active Directory).

Настройка обратной зоны5. Создается аналогично прямой зоне.(рисунок 4)

Рисунок 4

6. Перезапускаем rndc (sudo rndc reload).

7. Рестарт BIND (sudo service bind9 restart).

8. Проверяем работоспособность DNS-сервера на компьютере жертвы набираем команды nslookup lanlinux.ru и nslookup 192.168.1.1 (рисунок 5)

Рисунок 5

АтакаЗапускаем Netwox на атакующем компьютере (рисунок 6)

Рисунок 6

Выбираем 5й параметр

Выбираем 105 команду(Sniff and send DNS answers)(рисунок 7)

Рисунок 7

-h "имя зоны" -H "IP-зоны" -a "имя DNS-сервера" -А "на какой IP заменяем"

в нашем случае -h "lanlinux.ru" -H "192.168.1.1" -a "ns.lanlinux.ru" -A "192.168.1.33"

На компьютере жертвы набираем команду nslookup lanlinux.ruно ip адресс домена уже получаем подмененный(рисунок 8)

Рисунок 8

ЗащитаЧтобы настроить любой DNS сервер в качестве мастер сервера отвечающего за зону необходимо пройти несколько шагов:

сгенерировать ZSC и KSK;

прописать ключи в файл зоны;

подписать зону

Для создания ключей и подписи зоны используются утилиты входящие в состав BIND. Ключевая пара генерируется при помощи dnssec-keygen. Общий формат вызова ее прост:

dnssec-keygen –a алгоритм –b длина –n тип имя_доменаСоздаем ZSC:

dnssec-keygen –a RSASHA1 –b 1024 –n ZONE lanlinux.ru

Создаем KSK:

dnssec-keygen –r /dev/random -a RSASHA1 –b 1024 -n ZONE -f KSK lanlinux.ru

 В результате получим по два файла вида:

Kdomain++.key - открытый ключ

Kdomain ++.private – закрытый ключ

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

cat Klanlinux.ru.+*.key >> /etc/bind/lanlinux.ru.zone

Теперь необходимо подписать зону, то есть добавить RRSIG, NSEC и другие ассоциированные записи. Для этого вызывается утилита dnssec-signzone:

Формат: dnssec-signzone [-o zonename] [-N INCREMENT] [-k KSK.key] zonefile [ZSK.key]

 

dnssec-signzone -o lanlinux.ru -k Klanlinux.ru.+005+06697

lanlinux.ru.zone Klanlinux.ru.+005+61293

В результате на выходе получим файл зоны – lanlinux.ru.zone.signed в котором ресурсные записи будут рассортированы по алфавиту, а записи содержать необходимые поля RRSIG, NSEC и DNSKEY.

Включаем DNSSEC протокол, дописав в named.conf.option строчки

DNSSEC-enable yes;

DNSSEC-validation yes;

рестарт сервера sudo service bind9 restart

Теперь вновь пробуем провести атаку

так же запускаем Netwox с теми же параметрами и обращаемся с компьютера жертвы к DNS-серверу

и вот что мы получаем (рисунок 9)

Рисунок 9

DNS-ответ передается корректно, а Netwox дал сбой.Заключение

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

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

Список литературыDNS // Википедия — свободная энциклопедия [Электронный ресурс]. URL: https://ru.wikipedia.org/wiki/DNS

Ачилов Р. Создаём зоны DNS // Системный администратор, №6, 2006г. [Электронный ресурс] URL: http://samag.ru/archive/article/685.

Настройка сети вручную [Электронный ресурс] URL: http://help.ubuntu.ru/wiki/настройка_сети_вручную.

Петров А. Установка и настройка DNS Bind9 в Ubuntu [Электронный ресурс] URL: https://www.youtube.com/watch?v=69RmNxNrq6s.

Разработка, DNS сервер BIND [Электронный ресурс]. URL:

https://habrahabr.ru/post/137587/.

Давидович Д., Викси П. Защита DNS // Журнал сетевых решений, №2, 2000г. [Электронный ресурс] URL: http://citforum.ru/security/web/dns/.

Терминология и принципы работы DNS // Википедия — свободная энциклопедия [Электронный ресурс]. URL: https://ru.wikipedia.org/wiki/DNS.

Яремчук C. DNSSEC расширение к DNS для повышения безопасности. – //Системный администратор, №11, 2008г. [Электронный ресурс] URL: http://www.tux.in.ua/articles/2043.

DNS Pharming Attack. Reference: SEED Project.Laboratory Direction [Электронный ресурс] URL: https://www.youtube.com/watch?v=YiAr7SuXf7E.

DNS-атаки: полный обзор по схемам атак // Лаборатория информационный безопасности. [Электронный ресурс]. URL:

http://inforsec.ru/technical-security/network-security/77-dns-attack.

DNSSEC // Википедия — свободная энциклопедия [Электронный ресурс]. URL: https://ru.wikipedia.org/wiki/DNSSEC.

Настройка DNS сервера под управлением bind 9 [Электронный ресурс]. URL: http://www.lanlinux.ru/nastrojka-serverov/nastrojka-dns-servera-pod-upravleniem-bind-9-na-debian-linux.html

Похожие работы:

«специальность ЭЛЕКТРОННЫЕ ВЫЧИСЛИТЕЛЬНЫЕ СРЕДСТВА (дневная и заочная формы обучения) Квалификация специалиста: инженер-электроникВ настоящее время особое место занимают вычислительные средства, непосредственно связанные с реальными объектами (так называемые встраиваемые процессоры), предназначенные для решения задач прос...»

«УДК 519.2 Генерирование эвентологического распределения при заданных вероятностях событий. Нифонтов А. С., Научный руководитель д-р физ.-мат. наук, профессор Воробьев О. Ю. Сибирский Федеральный Университет Институт математики и ф...»

«5511165-43814Экскурсионная Программа Ваш краткий гид по океану возможных развлечений в Доминикане Экскурсии на целый день (с русским гидом, обедом и напитками)СТОЛИЦА САНТО-ДОМИНГО Санто-Доминго Deluxe (маленькая группа, познавательно, информативно).. 125$ -взр., 75$ дет. Индивидуально (с...»

«Филогенез. Развитие зрительного аппарата Эволюция зрительной системы Видимый диапазон электромагнитных волн занимает участок спектра, между ультрафиолетовым и инфракрасным диапазоном. Видимость — понятие чисто человеческое, такие лучи челове...»

«Протокол о допуске по закупке продукции для организаций системы "Транснефть" Лот № А-15.32.17 "Вычислительная техника и коммутационное оборудование" № А-15.32.17/Д06.10.2017 10:52г. Санкт-ПетербургИнформация о лоте: Наименование А-15.32.17 "Вычислительная техника и коммутационное оборудование" Начальная (максимальная) цена договора (лота) бе...»

«Филиал Московского государственного университета имени М.В. Ломоносова в г. Ташкенте Айтбаев Улугбек БатыровичВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА на тему "Поведение коллективов автоматов на целочисленной прямой" по нап...»

«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Факультет журналистики Кафедра современной периодической печати Заголовочные комплексы в аналитических материалах журнала Курсовая работа студентки 1 курса в. о. Фроловой БаженыПроверил: Ком...»

«Основные данные о работе Версия шаблона 2.1 Филиал Уфимский Вид работы Курсовая работа Название дисциплины Базы данных Тема Технология OLAP Фамилия студента Резванов Имя студента Дмитрий Отчество студента Т...»

«ДОГОВОР № 2-15 г. Красноярск _ 2015 г. Федеральное государственное бюджетное учреждение науки Институт вычислительного моделирования Сибирского отделения Российской академии наук в лице _, действующего на основании, именуемое в дальнейшем "Заказчик", с одной стороны, и, именуемое в д...»








 
2018-2023 info.z-pdf.ru - Библиотека бесплатных материалов
Поддержка General Software

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 2-3 рабочих дней удалим его.