22 Ноября 2024, 11:41

BIND

Автор turbo, 05 Августа 2008, 22:09

« предыдущая тема - следующая тема »

0 Пользователей и 1 Гость просматривают эту тему.

turbo

05 Августа 2008, 22:09 Последнее редактирование: 01 Февраля 2011, 16:51 от Zhek@Ch
[size="3"]BIND 9.5.0-P2, 9.4.2-P2 и 9.3.5-P2[/size]

Выпущено несколько корректирующих релизов DNS сервера BIND - 9.5.0-P2, 9.4.2-P2 и 9.3.5-P2, в которых устранены проблемы первой версии патча против атаки, позволяющей осуществить подстановку данных злоумышленника в кэш DNS сервера. Версии "P1" приводили к значительному понижению производительности высоконагруженных DNS серверов, обрабатывающих более 10 тыс. запросов в секунду.
http://www.isc.org/sw/bind/

turbo

10 Августа 2008, 12:10 #1 Последнее редактирование: 01 Февраля 2011, 16:54 от Zhek@Ch
[size="3"]Атака на последние версии DNS сервера BIND[/size]

Евгений Поляков обнаружил возможность осуществления подстановки данных в кэш DNS сервера BIND последней версии (9.5.0-P2, 9.4.2-P2 и 9.3.5-P2), содержащей исправления для защиты от подобной атаки методом Каминского.

Механизм случайного распределения номеров сетевых портов, используемый в последних версиях BIND для компенсации недостаточно большого размера поля с идентификационным номером запроса в DNS пакете теоретически растягивал время успешной атаки с нескольких минут до недели (16 битам query id + 64 тыс. портов). Евгению удалось добиться успешного проведения атаки на новые версии BIND приблизительно за 10 часов, при атаке с двух машин, имеющих доступ по гигабитному линку к DNS серверу (на практике такая атака может быть проведена с затрояненной машины в одной локальной сети с DNS сервером). Для успешного подбора номера порта и идентификатора пакета потребовалось отправить около 130 тысяч фиктивных пакетов.

Общие принципы совершения атаки методом Каминского прекрасно изложены в статье "An Illustrated Guide to the Kaminsky DNS Vulnerability", содержащей подробное объяснение всех тонкостей и снабженной наглядными иллюстрациями.
http://www.unixwiz.n...y-dns-vuln.html

ping_Win

09 Января 2009, 09:18 #2 Последнее редактирование: 01 Февраля 2011, 16:56 от Zhek@Ch
[size="3"]Новые релизы BIND и NTP с устранением уязвимости[/size]

Организация ISC выпустила обновление DNS сервера BIND (9.4.3-P1, 9.5.1-P1, 9.6.0-P1, 9.3.6-P1) и сервера для синхронизации точного времени NTP 4.2.4p6. Внеплановое обновление вызвано обнаружением уязвимости в OpenSSL, позволяющей принять сформированную злоумышленником подпись как корректную, при проверке подписи ключей DSA и ECDSA, используемые совместно с SSL/TLS. Данная уязвимость может быть использована для труднореализуемой подстановки злоумышленником (спуфинга) ответов для DNSKEY или NTP запросов, при использовании алгоритмов DSA или NSEC3DSA.

В качестве временного решения проблемы, можно отключить поддержку DNSSEC или добавить в BIND 9.3, 9.4, 9.5 "disable-algorithms . { DSA; };", а для BIND 9.6 - "disable-algorithms . { DSA; NSEC3DSA; };".

http://www.opennet.r...shtml?num=19686

ping_Win

22 Марта 2009, 14:19 #3 Последнее редактирование: 01 Февраля 2011, 17:00 от Zhek@Ch
[size="3"]В BIND 9.6.1b1, 9.4.3-p2 и 9.5.1-p2 исправлена проблема безопасности[/size]

В связи с обнаружением проблемы безопасности выпущены очередные обновления DNS сервера BIND: 9.6.1b1, 9.4.3-P2 и 9.5.1-P2. Проблема связана с недоработкой реализации внешних DNSSEC проверок (DLV - DNSSEC Lookaside Validation) в плане обработки обращений с указанием неподдерживаемого типа алгоритма цифровой подписи, например NSEC3RSASHA1. При указании такого алгоритма обращение к подписанным неизвестным алгоритмом доменам приводило в выводу ошибки проверки, вместо того чтобы обрабатывать их как обычные незащищенные запросы. Подобное поведение, например, привело к появлению проблем при работе с доменами .gov, которые недавно были переведены на использование механизма DLV.

http://www.opennet.r...shtml?num=20858

turbo

24 Апреля 2009, 21:26 #4 Последнее редактирование: 01 Февраля 2011, 17:00 от Zhek@Ch
[size="3"]Началась разработка DNS-сервера BIND 10[/size]

Организация Internet Systems Consortium анонсировала начало работы над версией DNS сервера BIND 10, разработку которой планируется завершить через 5 лет. О поддержке создания новой ветки уже объявили такие компании-регистраторы как AFNIC (Франция), CIRA (Канада), JPRS (Япония) и SIDN (Голландия). Ветка BIND 10, идущая на смену начавшего свое развитие в 1998 году релиза BIND 9, будет переведена на полностью модульную структуру, с выносом резолвера, подсистем для хранения данных и кода для обслуживания DNS зон в независимые модули.

Некоторые идеи, которые планируется реализовать в BIND 10:

 * Увеличение надежности, повышение стойкости к DoS атакам и способность работать до последнего, игнорируя возникающие ошибки (например, некорректные записи в DNS зонах);
 * Реализация возможности акселерации через схему бэкенд-фронтенд;
 * Не привязанность к конкретной модели хранения данных, подключение обработчиков хранилищ через модули. Включение в комплект модулей для хранения зоны в SQL базе, кеширования в памяти из файлов или использования встраиваемых БД;
 * Возможность определять в процессе сборки, на основе каких частей будет сформирована бинарная сборка. Например, может быть собран только кеширующий или только авторитативный сервер, что позволит создавать компактные версии bind, подходящие для использования во встраиваемых устройствах с ограниченными ресурсами;
 * Поддержка кластеризации: интеграция технологий, позволяющих организовать работу как единого целого нескольких копий BIND, размещенных на разных серверах;
 * Средства для интеграции BIND в программную инфраструктуру пользователя. Если сейчас базовая конфигурация оформляется в текстовых файлах, то появятся специальные программные интерфейсы для управления конфигурацией и мониторинга BIND из сторонних приложений. Например, можно будет более гибко организовать синхронизацию данных между DNS и DHCP серверами;
 * Контроль в процессе выполнения. Реконфигурация BIND 9 производилась исключительно через чтение файлов и примитивные rndc команды. В BIND 10 планируется реализовать более изящную и интерактивную схему контроля и мониторинга.

http://www.opennet.r...shtml?num=21421

turbo

30 Июля 2009, 21:08 #5 Последнее редактирование: 01 Февраля 2011, 17:05 от Zhek@Ch
[size="3"]Вышел релиз DNS-сервера BIND 9.4.3-p3, 9.5.1-p3, 9.6.1-p1 с исправлением уязвимости[/size]

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

Уязвимость появляется на первичных (master) управляющих DNS зонами серверах, независимо от настроек ACL и активности "dynamic update", вторичные (slave) серверы проблеме не подвержены. Крах возникает при получении dynamic update запроса, содержащего поле вида "ANY", когда в зоне присутствует как минимум одна RRset запись для данного доменного имени. При остановке сервера в лог выводится сообщение: "db.c:659: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed exiting (due to assertion failure).".

Проблема устранена в версиях Bind 9.4.3-P3, 9.5.1-P3, 9.6.1-P1. Обновление уже доступны для: FreeBSD, NetBSD, Debian GNU/Linux, Ubuntu и RHEL (для OpenSUSE, Gentoo, Mandriva, Fedora и Solaris пока обновлений не выпущено).

http://www.opennet.r...shtml?num=22796

turbo

17 Февраля 2010, 19:28 #6 Последнее редактирование: 01 Февраля 2011, 17:48 от Zhek@Ch
[size="3"]Увидел свет релиз DNS-сервера BIND 9.7.0[/size]

Вышел первый стабильный релиз новой ветки DNS-сервера BIND 9.7, основные улучшения в которой направлены на упрощения конфигурирования и обслуживания DNSSEC.

Главные новшества:

 * Реализована опция 'auto-dnssec' для осуществления полностью автоматического создания цифровой подписи для динамически конфигурируемых зон - ключи для подписи будут созданы автоматически и подписаны;
 * Упрощен процесс настройки расширения DLV (NSSEC Lookaside Validation), добавлена поддержка элемента конфигурации "dnssec-lookaside auto;", который позволяет избежать некоторых ручных манипуляций с dlv.isc.org;
 * Для упрощения конфигурирования DDNS (Dynamic DNS) добавлена новая утилита командной строки ddns-confgen;
 * Для named реализована опция "attach-cache", позволяющая привязать несколько представлений зоны (view) к общему кэшу;
 * Добавлена защита от "DNS rebinding" атак;
 * Изменены параметры по умолчанию, используемые при генерации ключей утилитой dnssec-keygen - без явного указания теперь генерируется 1024-битный ключ RSASHA1, а при указании опции "-f KSK" - 2048-битный ключ RSASHA1;
 * Поддержка определенной в RFC 5011 технологии автоматического обновления доверительных якорей (Trust Anchors);
 * Режим умного подписывания зон (dnssec-signzone -S), на основе доступных мета-данных определяющий какие ключи нужно использовать для заданной зоны;
 * В libdns представлено предназначенное для использования в сторонних программах новое API, учитывающее особенности работы DNSSEC;
 * Улучшена поддержка PKCS#11, включая поддержку аппаратных HSM-модулей Keyper и возможность явного выбора использования для работы движка OpenSSL.

В анонсе также сообщается, что в редких случаях при выполнении DNSSEC проверок наблюдается утечка памяти. Патч для решения проблемы уже создан, но к сожалению он не успел войти в состав BIND 9.7.0 и будет представлен только в версии 9.7.1.

http://www.opennet.r...shtml?num=25452

Zhek@Ch

15 Февраля 2011, 19:46 #7 Последнее редактирование: 15 Февраля 2011, 19:46 от Zhek@Ch
[size="3"]Релиз DNS-сервера BIND 9.7.3 и кандидат в релизы BIND 9.8 [/size]

Вышел релиз DNS-сервера BIND 9.7.3, в котором представлено только исправление 23 ошибок. Список улучшений версии 9.7.2, которая была отменена из-за обнаружения критической ошибки, можно посмотреть на данной странице. Дополнительно можно упомянуть о выходе первого кандидата в релизы BIND 9.8. Из улучшений BIND 9.8 можно отметить:

  • Вместо статической хэш-таблицы фиксированного размера для хранения кэша ответов от авторитативных DNS-серверов теперь задействован динамический расширяемый ADB hash;
  • Добавлена поддержка нового типа зон "static-stub", которые позволяют указать конкретные IP по которым следует обращаться для резолвинга заданных зон, в обход обслуживающих данные зоны DNS-серверов;
  • Добавлена поддержка механизма Response Policy Zones, позволяющего на лету вычислять "репутацию" для DNS-имен через создание специальной децентрализованной DNS-зоны (аналог DNSBL для борьбы с хостами спамеров и мошенников);
  • Добавлена поддержка DNS64, позволяющая автоматически синтезировать IPv6 AAAA-записи на основании IPv4 A-записей, а также IP6.ARPA CNAME блоки для существующих IN-ADDR.ARPA;
  • В Dynamically Loadable Zones (DLZ) добавлена поддержка динамических обновлений и возможность создания внешних DLZ-драйверов, не требующих прямой линковки на этапе сборки. Для использования внешних DLZ-драйверов в блоке update-policy добавлена поддержка нового типа соответствия "external";
  • В коде GSS-TSIG исправлено большое число ошибок, добавлено несколько новшеств и улучшена совместимость с динамическими обновлениями от Microsoft DHCP;
  • В утилите dig появилась новая опция "+onesoa", позволяющая запретить ввод дополнительных SOA-записей в AXFR-ответе;
  • В named.conf добавлена опция 'resolver-query-timeout', дающая возможность определить таймаут в секундах для рекурсивных запросов.

Rubik

24 Февраля 2011, 03:49 #8 Последнее редактирование: 25 Февраля 2011, 11:05 от Zhek@Ch
[size="3"]В DNS-сервере Bind 9 обнаружена DOS-уязвимость [/size]

В DNS-сервере Bind обнаружена уязвимость, позволяющая инициировать зависание процесса. Проблема проявляется при интенсивном потоке IXFR-пересылок или DDNS-обновлений - если почти сразу после успешной обработки IXFR-пересылки или DDNS-обновления сервер получит связанный с ними запрос может возникнуть бесконечное зацикливание, при котором обработка всех запросов блокируется.

Пользователям ветки 9.7.x рекомендуется обновить BIND до версии BIND 9.7.3.
Ветки BIND 9.4, 9.5, 9.6 и 9.8 уязвимости не подвержены.
В качестве временной меры защиты bind может быть запущен в однопоточном режиме (опция "-n1").

Главная ссылка к новости (http://www.isc.org/s...bind/advisor...)

Zhek@Ch

03 Марта 2011, 16:38 #9 Последнее редактирование: 03 Марта 2011, 16:38 от Zhek@Ch
[size="3"]Релиз DNS-сервера BIND 9.8.0[/size]

Компания ISC представила первый стабильный релиз новой ветки DNS-сервера BIND 9.8. Из улучшений BIND 9.8 можно отметить:

  • Вместо статической хэш-таблицы фиксированного размера для хранения кэша ответов от авторитативных DNS-серверов теперь задействован динамически расширяемый ADB hash. На нагруженных серверах новый хэш позволит избавиться от коллизий и исключит вызванные ими провалы во времени обслуживания запросов;
  • Добавлена поддержка нового типа зон "static-stub", которые позволяют указать конкретные IP по которым следует обращаться для преобразования имен (resolving) заданных зон, в обход обслуживающих данные зоны DNS-серверов;
  • Добавлена поддержка механизма Response Policy Zones, позволяющего на лету вычислять "репутацию" для DNS-имен через создание специальной децентрализованной DNS-зоны (аналог DNSBL для борьбы с хостами спамеров и мошенников);
  • Добавлена поддержка DNS64, позволяющая автоматически синтезировать IPv6 AAAA-записи на основании IPv4 A-записей, а также IP6.ARPA CNAME блоки для существующих IN-ADDR.ARPA;
  • В Dynamically Loadable Zones (DLZ) добавлена поддержка динамических обновлений и возможность создания внешних DLZ-драйверов, не требующих прямой линковки на этапе сборки. Для использования внешних DLZ-драйверов в блоке update-policy добавлена поддержка нового типа соответствия "external";
  • В коде GSS-TSIG исправлено большое число ошибок, добавлено несколько новшеств и улучшена совместимость с динамическими обновлениями от Microsoft DHCP;
  • В утилите dig появилась новая опция "+onesoa", позволяющая запретить вывод дополнительных SOA-записей в AXFR-ответе;
  • В named.conf добавлена опция 'resolver-query-timeout', дающая возможность определить таймаут в секундах для рекурсивных запросов;
  • Вместо "RTT banding" осуществлен уход к старому методу выбора сервера для выполнения рекурсивного запроса, при котором выбирается авторитативный сервер с минимальным RTT. В прошлых версиях с целью усиления защиты от атак по отравлению DNS-кэша применялся метод случайного выбора авторитативного сервера, который приносил больше вреда чем пользы из-за снижения эффективности формирования запроса (resolver обращался не всегда к самому быстрому авторитивному серверу, что приводило к возникновению задержек и сводило на нет топологические оптимизации).

Zhek@Ch

21 Мая 2011, 09:58 #10 Последнее редактирование: 21 Мая 2011, 09:59 от Zhek@Ch
[size="3"]В BIND 10, кроме DNS, будет интегрирован DHCP-сервер[/size]

Консорциум ISC, занимающийся развитием таких широко используемых в сети продуктов, как DNS-сервер BIND, DHCP-сервер ISC DHCP, сервер синхронизации точного времени ISC NTP и NNTP-сервер INN, объявил о планах по интеграции в будущую версию проекта BIND 10 поддержки протокола DHCP. По мнению разработчиков, функции DNS и DHCP тесно связаны между собой, а модульная архитектура BIND 10 как нельзя лучше подходит для объединения поддержки этих двух протоколов под эгидой одного проекта.

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

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

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

Основные мотивы создания новой реализации DHCP-сервера:

  • Мир вычислительной техники существенно изменился с момента проектирования ISC DHCP, скоро даже на мобильных телефонах будут использоваться многоядерные процессоры, гигабайты памяти и полнофункциональные операционные системы;
  • Сетевые технологии меняются. ISC DHCP был создан как первая реализация нового протокола DHCP, идущего на смену BOOTP. Теперь протокол DHCP обрел зрелость, его используют в сетях для управления миллионами компьютеров. Грядёт эра IPv6, при которой изменится подход к управлению и нумерации сетей;
  • Возникла потребность в программном обеспечении, которое может быть адаптировано под собственные нужны и расширено как администраторами, так и разработчиками.
Ожидается, что первый тестовый выпуск BIND 10 с поддержкой DHCP будет иметь характер начального прототипа с реализацией базовых функций работы с DHCP-пакетами, но ещё непригодный для выполнения реальных задач. В частности, в рамках начального прототипа планируется сделать:

  • Разработать библиотеку для работы с DHCP-пакетами, выполненную примерно в том же виде, как существующая сейчас библиотека для работы с сообщениями DNS. Библиотека будет поддерживать такие низкоуровневые функции, как сборка и парсинг пакетов;
  • Подготовить описание логики работы протоколов DHCPv4 и DHCPv6 в виде "машины состояний" (state machine);
  • Определить необходимые точки включения (хуки), описывающие как следует интегрировать новые обработчики и какие параметры использовать. Хуки будут определены для потоков данных между процессами, серверной логики и системы хранение данных;
  • Создать утилиты для тестирования производительности DHCP;
  • Оформить описание необходимых конфигурационных параметров.

Zhek@Ch

30 Мая 2011, 00:24 #11 Последнее редактирование: 30 Мая 2011, 00:24 от Zhek@Ch
[size="3"]Обновление DNS-сервера BIND 9.7.3-p1 и 9.8.0-p2 с устранением DoS-уязвимости [/size]

Представлены новые версии DNS-сервера BIND 9.7.3-p1 и 9.8.0-p2 в которых устранена уязвимость, которая может быть использована для инициирования отказа в обслуживании (крах рабочего процесса) путем наводнения сервера набором используемых в DNSSEC запросов RRSIG RRset (Resource Record Set).

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

Сервер Unbound также подвержен этой проблеме. Уязвимость исправлена в версии 1.4.10.


Zhek@Ch

06 Июля 2011, 22:52 #12 Последнее редактирование: 06 Июля 2011, 22:52 от Zhek@Ch
[size="3"]Обновление DNS-сервреа BIND 9.8.0-P4 и 9.7.3-P3 с устранением DoS-уязвимостей [/size]
 
Представлены корректирующие выпуски DNS-сервера BIND 9.8.0-P4 и 9.7.3-P3 в которых устранено несколько DoS-уязвимостей:

  • Возможность вызова краха сервера через отправку специально оформленного пакета. Проблема проявляется для серверов, работающих в рекурсивном и авторитативном режимах. Кроме патча обходных путей защиты нет. Для решения проблемы рекомендуется как можно скорее обновить BIND 9.x до версии BIND 9.8.0-P4 или 9.7.3-P3.
  • Две проблемы, которые могут привести к инициированию удаленного краха рабочего процесса (named). Проблемы проявляются только при включенной обработке рекурсивных запросов и использовании Response Policy Zones (RPZ) в сочетании с наличием в RPZ-зоне записей DNAME и CNAME;

Zhek@Ch

14 Июля 2011, 01:28 #13 Последнее редактирование: 14 Июля 2011, 01:28 от Zhek@Ch
[size="3"]Для DNS-сервера BIND 9 представлено исправление, существенно сокращающее время запуска [/size]

Как известно, одной из проблем DNS-сервера BIND 9 является очень медленный запуск при большом числе обслуживаемых DNS-зон. Если для сотен зон загрузка длится около минуты, то для сотен тысяч зон на запуск может уйти несколько часов (для миллиона зон - около 10 часов). Как оказалось, подобное поведение вызвано ошибкой разработчиков. После внесения изменений время запуска сервера с 500 тысячами зон сократилось с пяти с половиной часов до 2-3 минут, при росте потребления памяти на 2%. Исправление будет включено в состав будущих выпусков 9.8.1, 9.6-ESV-R5 и 9.7.4.

Проблема была вызвана неверным выбором размера пула одновременно выполняемых в BIND внутренних задач. При загрузке для обслуживания каждой зоны создается своя внутренняя задача, в рамках которой кроме разбора данных выполняются такие требующие времени действия, как отправка SOA-запросов master-серверам и отправка NOTIFY-уведомлений slave-серверам, сброс на диск дампа динамических зон и генерация DNSSEC-сигнатур. Так как по умолчанию число одновременно выполняемых задач было ограничено 8, все эти действия по сути выполнялись последовательно.


Zhek@Ch

17 Ноября 2011, 01:05 #14 Последнее редактирование: 17 Ноября 2011, 01:05 от Zhek@Ch
[size="3"]Опасная DoS-уязвимость в DNS-сервере BIND 9 [/size]

Консорциум ISC уведомил пользователей об обнаружении в DNS-сервере BIND 9 уязвимости, позволяющей удалённо вывести DNS-сервер из строя, отправив специально сформированный рекурсивный запрос. Подробности о методе совершения атаки не сообщаются, известно только то, что данная уязвимость уже активно эксплуатируется злоумышленниками в сети.

Исправление пока недоступно, но в ISC обещает опубликовать патч в ближайшие часы, после завершения его тестирования. В качестве обходного пути защиты можно ограничить выполнение рекурсивных запросов только для доверительных хостов. Уязвимости подвержены все версии BIND 9.x. Определить факт атаки можно по краху named с выводом в лог записи "INSIST(! dns_rdataset_isassociated(sigrdataset))".