Выпущены обновленные версии DNS сервера BIND: 9.4.1-P1 (http://comments.gmane.org/gmane.network.dns.bind.announce/104), 9.3.4-P1 (http://comments.gmane.org/gmane.network.dns.bind.announce/105), 9.2.8-P1 (http://comments.gmane.org/gmane.network.dns.bind.announce/106) и 9.5.0a6 (http://comments.gmane.org/gmane.network.dns.bind.announce/107), с исправлением уязвимости (http://www.trusteer.com/docs/bind9dns.html) дающей возможность злоумышленнику организовать отправку клиенту фиктивных ответов DNS сервера.
Проблема заключается в возможности предсказания с высокой вероятностью идентификатора следующего DNS запроса. Злоумышленник может сгенерировать поддельный ответ, который будет отдан на запрос клиента, если BIND работает в режиме резолвера или когда первичный DNS сервер осуществляет оправку NOTIFY-пакета вторичному.
Кроме того, введены ограничения по умолчанию для рекурсивных запросов и обращений к кэшу, теперь по умолчанию устанавливаются ACL:
options {
recursion yes; // default
allow-recursion { localnets; localhost; };
allow-query-cache { localnets; localhost; };
...
};URL: http://it.slashdot.org/article.pl?sid=07/07/24/1614205&from=rss
Новость: https://www.opennet.ru/opennews/art.shtml?num=11539
>Про "раз в месяц" поподробнее, пожалуйста. С указанием (хотя бы) ссылок на 2 предыдущих месяца.А что, этой идиотской уязвимости мало? Да за такую глупость надо навсегда запрещать писать какой-либо код. Мало что-ли в сети открытых референсных генераторов случайных чисел? Если посмотреть на историю уязвимостей BIND, то по нанесенному ущербу ему уступит только sendmail.
Интересно, сколько раз надо залатать очередную критическую уязвимость с удаленным выполнением, что бы понять, что горбатого только могила исправит?
Главное - ляпнуть сначала про ежемесячность, а когда конкретный вопрос задали - начинать отмазываться. Ну гордись своим DJB DNS. Только не лопни от гордости. А ещё лучше - напросись в команду разработчиков в ISC - и научи их программированию. Умник, ...ля. Только трындеть и умеем. Пузыри и понты пускать.
Sampan, не надо фанатизма, успокойтесь Вы говорите просто брет...
К сожелению, если Вы ничего не понимаете в ПО или в разработке ПО и тд...то посторайтесь прочесть что-то, чтоб понять хоть принцип работы служб DNS, а так же теории безопатсности dns...
А если нет своего ума - обратитесь к компетентным инженерам, а не малолетним бомжам...
Вася. Бездоказательно ляпнуть "Вы говорите просто брет" большого ума не надо. Я бы сказал наоборот, обычно подобная фраза полностью раскрывает интеллектуальный уровень и компетенцию говорящего.Вместо глупых и голословных утверждений почитайте-ка лучше описание уязвимости: "алгоритм, по которому генерируется случайная 16-битная транзакция и ее идентификатор в действительности случайными не являются и подлежат подделке и расшифровке. Это позволит атакующему подделать ответ и переправить пользователя по подложному адресу". А затем немного подумайте (поверьте, понять эту уязвимость совсем не сложно). И если у Вас еще осталось немного серого вещества, то Вы согласитесь со мной, что в 2007 году за подобные "перлы" в кодировании нужно, как минимум, руки отрубать, что-бы больше до клавиатуры не касался.
ну ты читай раз не понимаешь,
я могу тебе сквзать по-секрету - что многие многие и очень многие выбрали бинд, и что самое странное большинство работает на более старых версиях...Если я запущу бинд 9.2 ты мне сможешь там удалить подменить или добавить данные в зоне или конфигурации ???
я думаю, что нет.
А вот если я куплю у маленьких карликов 30 минут доса и направлю его на тебя то тебя нечего не спасет, даже твой любимый патч для freebsd-панталон.
>Если я запущу бинд 9.2 ты мне сможешь там удалить подменить или добавить данные в зоне или конфигурации ??? я думаю, что нет.Батенька, да Вы дурак!
Эта уязвимость не про подмену зон или конфигурации. Это про то, что достаточно легко возможно подменить DNS ответ от уязвимого сервера. Сами провайдеры при этом не страдают. Страдают их клиенты, которым теперь можно подсунуть произвольный IP адрес в ответ на запрос, например, www.citybank.com.
Уведомление об этой уязвимости срочно разослали прежде всего крупным DNS хостерам.
>я куплю у маленьких карликов 30 минут доса и направлю его на тебя
Точно дурак!!!
Пожалуй, стоит поднапрячься и поставить DJB DNS, обещание автора выплалить $500 за уязвимость обнадёживает, да и отзывы хорошие (в отличие от BIND). SPF - sender policy framework - надеюсь в DJB будет работать (по идее с TXT записями не должно быть проблем)
нормально работает, на http://www.openspf.org/ есть мастер для создания записи
А в качестве бонуса получите уменьшение нагрузки на систему )
P.S. Не сочтите за рекламу, но на http://lithium.opennet.ru/ есть IMHO достаточный объем информации чтобы попробовать, + в конце статей есть ссылки на другие источники информации.
У меня за все время использования была только одна проблема -- djbns не обрабатывает SIGPIPE (DJB по этому поводу написал, что он просто забыл добавить этот обработчик) и при совпадении таких факторов как глючный свитч (часто рвались длинные по времени TCP-сессии) и какие-то огромные PTR-записи, передаваемые по TCP, соединения рвались и он падал. Однако из-за того, что его тут же поднимал daemontools, узнал об этом только по разному uptime у двух кэшей. Проблема решилась добавлением одной строки в стартовый скрипт...
А так вообще про него не вспоминаешь, разве что раз в пару месяцев размер кэша в памяти немного поднастроишь -- нагрузки растут... Но в обычной локальной сети фирмы этот параметр вряд ли когда нужно будет трогать...
Хе хе хе!
История повторяется!
Господа, эта атака имеет смысл только в одном случае-если злоумышленник может прикинуться днс-сервером(т.е. подделать свой IP итп) и послать сгенеренный ответ клиенту. Но в таких сетях о какой-либо безопасности речи не идет.
Читайте внимательно описание проблемы - заражению подвержен КЕШ бинда!!! Атакующий может зафлудть бинд ложными ответами на его попытки разрешть какое-нибудь имя! Заражается кеш! Это пипец господа...
Это пипиец..., караул спасите ...
счас сломают мой бинд... ААААААААААА
все пошел молится, потом вешаться...блин а может пойти к началству с этой новостью.. пусть зарплату поднимают...
и че он там подменит то ?
расскажите как это зделать в локальной сети ?
у меня есть к примеру хост А - сервер(ДНС)-1
хост А - хочет например зайти в свой банк-интфейс и шлет соответвенно к серверу-1 dns-запрос coolbank.com...
допустим есть злоумышленик хост B желающий отправит клиенту ложную информацю о том, что coolbank.com -> на его машине)Расскажите каким образом это будет реализованно ?
То есть по ссылкам мы не ходим, по англицки не не умеем?
Что ISC плохо дыряво пишут - факт. Можно ли везде сменить BIND на другое - нет, так как BIND это некоторым образом стадарт реализованный в коде.
я в качестве резолвера и кеша powerdns-recursor использую, а bind только в качестве авторитетного, по фичастости с ним мало кто может сравниться
Стандарт это RFC1034 RFC1035 и последующие, а бинд это кривая реализация. Если у вас нет необходимости в каких-то извращениях доступных только в нем, то не стоит и связываться. Этот софт уже давно дескредитировал себя как решение на которое можно положиться... Лишняя головная боль.
да, мне несколько view нужны, причём, как на первичном, так и на вторичном сервере
>да, мне несколько view нужныВ DJB DNS это есть - можно реализовать.
а как view в DJB DNS на вторичном синхронизироваться будут, на bind сейчас через tsig
В комплект DJB входит axfrdns (без криптования соединения). Это на случай, если slave BIND. Если slave тоже DJBDNS то очень удобно rsync через ssh.
где скачать новую версию dns???
одно название DjB уже выводит и только формирует негатив...
как стадо глупых карликов все в один голосо орете "бинд го*но", а конкретно по-делу 0.
>одно название DjB уже выводит и только формирует негатив...imho это Ваши личные проблемы.
>как стадо глупых карликов все в один голосо орете "бинд го*но", а
>конкретно по-делу 0.по делу уже приводили ссылки, на securityfocus можно посчитать сколько их уже есть.
Также можно почитать http://cr.yp.to/djbdns/blurb/security.html
Лично меня кроме всего перечисленного сильно раздражает небезопасное отслеживание кэшем BIND'а цепочки полномочий. Если перенести NS-сервера на другие IP и оставить работать старые, то по истечении всех TTL он все равно ходит на старые, пока их не остановишь... Также, опрос знакомых с BIND показывает что при сопоставимых нагрузках djbdns расходует намного меньше ресурсов.
http://ospf-ripe.livejournal.com/1601.html -- в тему.
у меня и для bind через rsync файл с описанием зон на вторичнике перестраивается, сами зоны, как всегда, через notifyrsync -az -e ssh bindsync@80.0.0.2:/var/named/etc/namedb/primaries.zones /var/named/etc/namedb/primaries.zones
if [ $? -ne 0 ]; then
echo "rsync failed"
exit 1
fised -e '/^\/\//D' -e '/^#/D' -e '/allow-.*;/D' \
-e '/;/s/master\//slave\//g' \
-e '/type.*;/s/master/slave/g' \
-e '/type.*slave.*;/ a\
masters { 80.0.0.2; } ;' \
/var/named/etc/namedb/primaries.zones > /var/named/etc/namedb/secondaries.zonesif [ $? -ne 0 ]; then
echo "sed failed"
exit 1
fi/usr/sbin/rndc reload > /dev/null
Поначалу использовал этот же самый Bind и как резолвер и кеш, но когда bind отжирал памяти >300Mb rndc reload уже не работал, даже остановить bind было проблемой, по 5 минут висел после rndc stop
поэтому пересел на powerdns-recursor, Bind чисто authoritativeDjB использую на почтовиках в качестве резолвер и кеша (rbl много запросов генерят, до 4000/c доходит), в портах freebsd есть патч persistent cache, при перезапуске реально помогает