"IPv6 Neighbor Discovery Protocol routing vulnerability (http://security.freebsd.org/advisories/FreeBSD-SA-08:10.nd6.asc)" - уязвимость в реализации IPv6 протокола FreeBSD. Злоумышленник из близлежащей сети может использовать протокол Neighbor Discovery Protocol для создания или изменения записи в кэше соседних IPv6 сетей (neighbor cache) на FreeBSD шлюзе. Проблема присутствует во всех поддерживаемых версиях FreeBSD - 6.3 и 7.0. В качестве временного решения можно блокировать пакетным фильтром NDP (ICMPv6 type 135) сообщения из внешних сетей.URL: http://security.freebsd.org/advisories/FreeBSD-SA-08:10.nd6.asc
Новость: http://www.opennet.me/opennews/art.shtml?num=18215
не актуально
>не актуальноКому-то может и нет. А вообще интересно сколько ещё дыр в реализации IPv6 найдут, не говоря уже о проблемах самого протокола?
А тут на самом деле все просто. Хороший протокол должен быть прост как топор, изящен и с понятной, четко определенной логикой.Тогда там будет нечего ломать.TCP этому не соответствует. Дурь с фрагментацией, MSS, и вагоном прочей мутотени кардинально усложняют протокол. К тому же делался он во времена когда хакеры, вирусы и трояны были мифом. Да и половина других протоколов (ну вон хоть тот же DNS) отнюдь не сделаны с допущением что их будут долго и качественно пытаться сломать.Посему у того же DNS есть (неустранимые в рамках стандартного варианта протокола) дыры.
IPv6 с одной стороны сделали проще местами.Но только местами.С другой стороны наворотили для удобства юзеров.Это и удобства для хакеров заодно, потому что вопросами "а что будет если нехороший парень пошлет такие-то пакеты вон туда?" никто судя по всему не заботился.Заодно надо было под шумок перепахать TCP, устранив его некоторые фирменные грабли, как раз возможность есть.Но почему-то его предпочли оставить как есть.А зря.ИМХО еще не раз будут такие новости...
> TCP этому не соответствует. Дурь с фрагментацией, MSS, и вагоном прочей мутотени кардинально усложняют протокол.Интересно, а как быть, если фрагментация изначально существует в IP, и вызвана она разным MTU? И вообще, попробуй сделать свой протокол с аналогичной (или лучшей) эффективностью работы в реальных сетях со всеми их проблемами!
Конечно, в TCP многое следовало бы сделать иначе (наприменр, ввести функции авторизации и компрессии прямо на уровне протокола); но "иначе" != "проще" !!!
>Интересно, а как быть, если фрагментация изначально существует в IP,Просто: при разработке нового протокола сделать так чтобы не существовала.Замочив проблему как класс.Вроде кой-что по этой части даже сделано.
>и вызвана она разным MTU?
Никто не спорит, если захотеть создать геморрой то эта цель вполне достижима.Ну вот, достигли.В итоге дошло до того что авторы прикладных программ (которых все это вообще по идее колебать не должно) для достижения оптимальной производительности подчас трахаются с определением максимально возможного MTU самопальными методами.Как раз чтобы срубить фрагментацию и достичь максимальной производительности (reassembly пакетов тормозит и роутеры и протокольный стэк).
>И вообще, попробуй сделать свой протокол с аналогичной
>(или лучшей) эффективностью работы в реальных сетях со всеми их проблемами!А тут придется выбирать - или колосс на глиняных ногах с кучей костылей и подпорок или простой дизайн но может быть чуть менее эффективный в каких-то ситуациях.Как пример - вон, ньюс про SACK - "хотели как лучше, а получилось как всегда".Можно подумать без него во многих случаях станет намного хуже.Ага.А вот хаксорам очень удобно срать пачками SACK пакетов зато.При том анализ там для Linux но судя по описанию - остальные не неуязвимы а просто необследованы.
>Конечно, в TCP многое следовало бы сделать иначе (наприменр, ввести функции авторизации
>и компрессии прямо на уровне протокола); но "иначе" != "проще" !!!Нафиг не нужно.Богу богово, а кесарю кесарево.TCP это протокол передачи данных а не их сжатия или авторизации кого либо.Случаи бывают разные.Например, публично доступному серверу нафиг не впилась авторизация а вот стэк это усложнит и нагрузит.А компрессия хоть-там-каким алгоритмом на хотя-бы обычном ГИГАБИТЕ... а вы попробуйте, потом расскажете.К тому же наверняка можно будет попытаться пихать наиболее неудобные для декомпрессии специально сформированные данные, пригрузив процессор атакуемой машины на всю катушку.
>А тут на самом деле все просто. Хороший протокол должен быть прост
>как топор, изящен и с понятной, четко определенной логикой.Тогда там будет
>нечего ломать.Это конечно хорошо, но с такими критериями сложно реализовать что-то =)
Вообще, для меня тема протоколов в ближайшие месяцы станет очень актуальной. Т.к. необходимо реализовать свой протокол и хотелось бы избежать граблей. Естественно сложность моей "поделки" и TCP/IP несравнима, но и знаний (опыта) у меня гораздо меньше. Поэтому взгляд пал на средство верификации SPIN и книжку "Design and validation of computer protocols". Интересно какие ещё есть средства разработки и верификации протоколов?
Было дело реализовывал простенький протокол для обмена данными с устройством, так и то чуть мозг не сломал, рисуя диаграмки и отслеживая возможные состояния. Как можно проанализировать все возможные "затыки" в протоколах уровня TCP даже представить не могу.
>разработки и верификации протоколов?Работающая голова на плечах, учитывающая реалии в которых будет работать протокол?А то если уж такие гранды которым десятилетия и по сей день несовершенны - почему бы собственно не попробовать подумать самому?А вдруг лучше получится?Совсем не факт, конечно, но попытаться можно.В частности и с другими goals :)
>Было дело реализовывал простенький протокол для обмена данными с устройством, так и
>то чуть мозг не сломал, рисуя диаграмки и отслеживая возможные состояния.Это да.Но чем проще протокол тем меньше подобного геморроя.Кроме того - ну например я когда-то писал реализацию X-Modem.Мало того что его в природе 3 варианта так еще сам протокол крайне бестолковый, плохо переносит ошибки, легко теряет синхронизацию до фатальных последствий а некоторый софт еще и крайне нестандартно себя ведет (на что пришлось изгаляться с воркэраундами).Наплевал на все и сделал свой протокол, простой, надежный и стабильный как танк.Пусть и не самый быстрый на свете, но (учтя реалии линии по которой он работает в виде почти нулевого пинга и отсутствия хакеров) вполне нормальный.Для своих условий работы.Отладил протокол за сутки и сразу стало и быстрее и менее глючно.Можно шнурок из девайса на 10 секунд выдернуть, воткнуть и дальше все заработает как ни в чем не бывало.
>Как можно проанализировать все возможные "затыки" в протоколах уровня TCP даже
>представить не могу.Судя по последним ~3 новостям никто полностью их и не анализировал... а вот хакеры очень любят всякие граничные и клинические случаи проверять, на чем протоколы традиционно и скисают.Собственно, делая протокол надо просто держать в голове все потенциальные проблемы с которыми он столкнется в жизни.Если это хакеры - при создании протокола надо просто думать как хакер.Соображая "а как бы этому протоколу исхитриться подгадить?".И делать протокол так чтобы подгадить было как можно труднее.IP, TCP и UDP делались явно без такой мысли в голове.Они могут переживать случайные проблемы.Но вот с злонамеренно создаными у них все плохо.У IPv6 cудя по всему все будет еще веселее.Там ради удобства юзеров всякие там объявления о наличии роутеров и прочее.Хаксорам явно будет где развернуться :)
Мне сегодняшнее состояние TCP/IP напоминает ситуацию с преодолением сверхзвукового барьера, когда, до этого хорошо зарекомендовавший себя самолет, пытались адаптировать для полета на сверхзвуковых скоростях... Только разваливался он постоянно, пока принципиально новые технологии не реализовали, хотя наверное уместней был бы пример с поездами на магнитной подушке - сколько ни старайся, а 300 км в час по ЖД-полотну не выжмешь. TCP/IP сейчас тоже по швам трещит, 40 лет назад как-никак совсем все было по другому, то что сейчас через очередной хак под именем IPv6 пытаются на лишний десяток лет оттянуть агонию - проблемы не решает, а лишь усугубляет запущенность положения.
Как раз на скорости 300 км/ч и ходит TVG.
Разумеется, по специальному полотну - но все-таки по рельсам.
Зато вот это - весьма актуально
http://uinc.ru/news/sn10817.html
>Зато вот это - весьма актуально
>http://uinc.ru/news/sn10817.htmlЧто же будет когда хаксоры посмотрят на жаббер... :)))