Демократия или диктатура: чем чреват обязательный переход на IPv6

АКТИВНОЕ ВТОРЖЕНИЕ ПРОТОКОЛА IPV6 В ЖИЗНЬ IT-СПЕЦОВ ПРОДОЛЖАЕТСЯ. ВСЕ БОЛЬШЕ И БОЛЬШЕ ОПЕРАЦИОННЫХ СИСТЕМ, МАРШРУТИЗАТОРОВ, РАЗРАБОТЧИКОВ СЕРВЕРОВ И ПРОЧЕГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РАПОРТУЕТ О ЕГО ПОДДЕРЖКЕ, ВЫЗЫВАЯ У ПОЛЬЗОВАТЕЛЕЙ ЕСТЕСТВЕННОЕ НЕДОУМЕНИЕ: ЧТО ЭТО ТАКОЕ, ЗАЧЕМ ОНО ВООБЩЕ НУЖНО И КАК ОБСТОЯТ ДЕЛА С БЕЗОПАСНОСТЬЮ?

Введение в протокол IPv6

Ужасным недостатком протокола IPv4 (и основным мотивом перехода на IPv6) оказалась ограниченное количество IP-адресов, катастрофическая нехватка которых ощущается уже сейчас. И хотя DHCP-серверы, выдающие динамические IP, и системы трансляции сетевых адресов NAT (Network Address Translation) до некоторой степени смягчают остроту проблемы, как ни крути, а 32-битное поле обеспечивает лишь 4.294.967.296 уникальных IP-адресов, часть из которых зарезервирована под служебные нужды, так что приведенная цифра еще и слегка завышена. В эпоху молодости интернета, когда количество узлов исчислялось десятками, это ограничение не казалось столь существенным недостатком (точнее, никому в голову не приходило назвать его «ограничением»), но взрывной рост сети сделал свое дело, и в ближайшем будущем к интернету планируется подключить холодильники, микроволновые печи и даже унитазы, требующие IP-адреса.

Стало ясно, что «дальше так жить нельзя» и протокол IPv4 нужно либо расширять, либо переходить на нечто совершенно иное.

Широко распространенное заблуждение гласит, что IPv6 представляет собой слегка доработанную версию IPv4. Но он возник не вчера и даже не позавчера. Еще в начале 1990 года в RFC 1750 появилось первое упоминание о грядущей нехватке IP-адресов, которое дало толчок к рассуждениям и поискам новых решений. Для решения подобных проблем в 1993-1994 годах комитет IETF сформировал рабочую группу «IPng Area» (IP Next Generation).

К концу 2000 года протокол IPv6 достаточно «созрел» и оброс большим количеством спецификаций, «ядро» которых состоит из следующих документов: RFC 2460 — базовое описание протокола, RFC 4291 — система адресации узлов, RFC 2461 и RFC 4311 — поиск соседних узлов (Neighbor Discovery), RFC 4443 — ICMP-версия для IPv6 и т.д. Изучив их, с удивлением обнаружим, что IPv6 фактически представляет собой смесь идей, почерпнутых из протоколов ISO CLNP (также известным под кодовым именем TUBA), IPv7 (он же TP/IX, описан в RFC 1475) и гибрида SIPP (описан в RFC 1710). Причем IPv6 архитектурно стоит гораздо ближе к ISO CLNP, чем к своему «прародителю» IPv4.

Факт первого коммерческого использования протокола IPv6 относится к 20 июля 2004 года, когда ICANN добавил IPv6 AAAA-записи для Японии (.jp) и Кореи (.kr), сделав их видимыми для всего мира. А чуть позже в этот список попала и Франция (.fr). Естественно, в локальных сетях протокол IPv6 может использоваться и без «санкции» со стороны ICANN, но очень трудно представить себе локальную сеть, состоящую более чем из 232 узлов. Тем не менее, джин уже выпущен из бутылки — IPv6 распространяется по миру, образуя своеобразные «островки», соединенные тоннельными протоколами типа IPv6-over-IPv4.

Достоинства и недостатки IPv6

IPv6 использует 128-битную адресацию, что дает нам порядка 3 в степени 1038 уникальных адресов. Это число настолько велико, что даже если каждый атом земного шара подключится к интернету, в его распоряжение может быть выделено, по меньшей мере, семь IP-адресов! Другими словами, адресный голод закончится раз и навсегда.

Еще одно преимущество заключается в том, что при переходе с IPv4 на IPv6 протоколы прикладного уровня (TCP/UDP) и использующее их программное обеспечение ничего не «почувствуют», а значит, их не придется переписывать. Во всяком случае, так утверждает реклама. Но в IPv6 полностью изменился формат записи IP-адресов - теперь они записываются в виде девяти групп из четырех шестнадцатеричных цифр, разделенных знаком двоеточия. В результате типичный IPv6-адрес выглядит как «2001:0DB8:85A3:08D3:1319:8A2E:0370:7334». Попробуй ввести такой с клавиатуры! Может ведь возникнуть потребность связаться с web-сервером, не имеющим доменного имени. Тогда мы должны будем ввести в адресную строку браузера следующую абракадабру: «http://[2001:0DB8:85A3:08D3:1319:8A2E:0370:7344]:8080/», заключив IPv6-адрес в квадратные скобки, за которыми (при необходимости) может следовать адрес порта.

Фрагментация пакетов из IPv6 была исключена во благо маршрутизаторов и брандмауэров. В IPv4 передаваемый пакет при необходимости разбивается на пакеты меньшего размера, передаваемые вперемешку со всеми остальными, причем порядок поступления пакетов может отличаться от порядка их взаимного расположения. То есть чтобы проанализировать пакет на «вшивость», брандмауэр должен собрать весь пакет целиком, складывая поступающие фрагменты в свой локальный стек и задерживая их поступление по каналу. И только по приходу последнего фрагмента (который вполне может оказаться первым физическим фрагментом пакета, несущим в себе заголовок с адресом отправителя и получателя) решить, пропускать его или нет. При этом накопившиеся в стеке фрагменты выплевываются всем скопом, и в сети возникает перегрузка, а сам брандмауэр требует значительного размера оперативной памяти. И большинство IPv4-атак было основано именно на ошибках реализации ассемблера/дизассемблера пакетов (сборщика/разборщика).

В IPv6 фрагментации уже нет, и максимальный размер пакета составляет 65535 байта, что существенно превышает величину, поддерживаемую большинством маршрутизаторов. Поэтому узел-отправитель должен самостоятельно определить величину MTU (Maximum Transmission Unit – максимальный передаваемый блок), руководствуясь алгоритмом, описанным в RFC 1191, и разбить IPv6 пакет на заданное количество фрагментов, оформив каждый из них как самостоятельный IPv6-пакет. Нагрузка с марштутизаторов теперь перенесена на узлы-отправители, требования к мощности которых существенно возросли (особенно на быстрых каналах).

Другая интересная концепция — опция необязательных подключаемых заголовков (concatenated headers), содержащих различную служебную информацию. В настоящее время поддерживается шесть типов дополнительных заголовков, одним из которых является заголовок фрагментации, содержащей идентификатор дейтаграммы, номер фрагмента и бит, указывающий, является ли данный фрагмент последним. Выходит, что в IPv6 фрагментация все-таки есть, правда, в отличие от IPv4, фрагментировать пакеты может только узел-отправитель, а не промежуточные марштутизаторы. Кстати говоря, посылка фрагментированного IPv6 пакета позволяла захватить контроль над OpenBSD, и это была вторая крупная дыра, обнаруженная 13 марта 2007 года, что доказывает сырость реализации IPv6.

Еще протокол IPv6 способен поддерживать пакеты сверхбольшого размера (jumbograms) вплоть до 4 Гбайт, что очень полезно для суперкомпьютеров, обрабатывающих не только 64-килобайтные данные. На первый взгляд, jumbogram'ы создают серьезную проблему. Ведь если какой-то зловредный пользователь отправит 4-гигабайтный IPv6-пакет в медленную сеть, то остальные пакеты надолго застрянут в очереди. На самом деле, этого не произойдет, поскольку максимально допустимый размер пакета определяется промежуточными марштутизаторами и очень часто составляет 576 байт, так что ни о каких «запорах» сети не может быть и речи.

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

Тоннели и проблемы безопасности

Для обеспечения обратной совместимости большинство узлов, поддерживающих IPv6, также поддерживают и IPv4. Данная технология получила название «двойного стека» (dual stack) и описана она в RFC 4213. Ее достоинство в том, что сервер, оснащенный двойным стеком, может обслуживать как IPv6-, так и IPv4-клиентов. Правда, с одной небольшой оговоркой. Старшие разряды IPv6-адреса заполняются нулями, и мы получаем обыкновенный 32-битный IPv4-адрес (про дефицит которых уже говорилось выше), только записанный в IPv6-нотации. К «полноценному» IPv6-адресу IPv4-клиент подключиться не сможет.

С маршртутизаторами — та же самая история. Поскольку IPv4 в ближайшие несколько лет умирать не собирается, IPv6-маршрутизатор вынужден поддерживать технологию двойного стека, что предъявляет повышенные требования к ресурсам и увеличивает сложность реализации (а значит, и вероятность возникновения ошибок). Теоретически, можно выключить стек IPv4, создав «чистый» IPv6-узел для общения с себе подобными, но в существующих операционных системах это сделать очень непросто, а потому «чистых» IPv6-узлов в природе не наблюдается. И это несмотря на то, что количество «гибридных» стеков неуклонно растет, поскольку в последних версиях BSD, Linux, Mac OS X и Windows стек IPv6 автоматически включается инсталлятором по умолчанию.

Вот только если между двумя IPv6-узлами окажется расположен хотя бы один IPv4-маршрутизатор, то «совокупляться» им придется либо по технологии двойного стека, либо использовать тоннели IPv6-over-IPv4. Таких тоннелей много, но принцип действия у них один. IPv6-пакет укладывается в IPv4, передаваемый обычным путем, а получатель проделывает обратную операцию.

Но как мы сможем отправить IPv4-пакет узлу, имеющему только IPv6-адрес? Единственный выход заключается в установке специального сервера, устроенного наподобие Proxy. Отправитель берет IPv6-пакет, кладет его внутрь IPv4-пакета, отправляет одному из глобальных proxy-серверов с двойным IPv6/IPv4-стеком. Сервер извлекает IPv6-пакет, смотрит на адрес получателя и передает его следующему рroxy-серверу, соединенному с получателем только IPv6/IPv4-марштутизаторами. Естественно, таких рroxy-серверов должно быть много (в противном случае они просто лягут под нагрузкой).

В Windows Vista встроен тоннельный протокол Teredo (включенный по умолчанию), разработанный сотрудником Microsoft по имени Christian Huitema с претензией на всеобщий стандарт и потому детально описанный в RFC 4380 (www.rfc-editor.org/rfc/rfc4380.txt). Специалисты из Symantec'a проанализировали Teredo, подвергнув его резкой критике:

www.symantec.com/enterprise/security_response/weblog/2006/11/the_teredo_protocol_tunneling.html, www.symantec.com/avcenter/reference/ATR-VistaAttackSurface.pdf и www.symantec.com/avcenter/reference/Teredo_Security.pdf

Teredo, инкапсулируя IPv6-пакеты внутрь UDP-дейтаграмм, переедаемых через IPv4 (причем, уровень вложенности формально неограничен и при желании можно создать «матрешку» или слоеный торт «Наполеон»), без труда обходит существующие защитные механизмы типа брандмауэров, NAT'ов, систем обнаружения вторжений и т.д., поскольку все, что они видят — это «честный» UDP-пакет, посылаемый на один из внешних узлов. Истинный целевой адрес, порт и содержимое пакета — скрыты внутри IPv6. Чтобы его «достать», брандмауэр/IDS должен знать о существовании Teredo. С учетом новизны Windows Vista вероятность такой осведомленности крайне невелика, и на время смены оборудования для хакеров, червей и прочих вирусов наступает настоящая благодать. И если программные защитные комплексы еще хоть как-то можно обновить, то «железо» придется отправлять на свалку и приобретать новое (для начала дождавшись его появления на рынке). Впрочем, то же самое относится и к остальным тоннельным протоколам, реализованным вне Microsoft и поддерживаемым операционными системами Linux и xBSD. Например, 6to4, описанном в RFC-3056: http://tools.ietf.org/html/rfc3056. Благо, 6to4 появился в 2001 году, и к настоящему моменту многие производители уже успели обеспечить его поддержку.

Второе обвинение, предъявляемое протоколу Teredo, серьезнее: Teredo «глобализует» локальные адреса, делая их доступными отовсюду, что расходится с политикой безопасности многих компаний (достаточно вспомнить о нашумевшем деле с определением IP-адреса сети Пентагона). О лучшем сканере узлов, закрытых NAT'ом или брандмауэром, хакеры не могли и мечтать. И выход Vista — огромный подарок для IT-хулиганов, активность которых значительно возрастет, а защитные средства за один-два дня не появятся!

Сырость IPv6 и атаки на него

Протокол IPv6 очень молод. Настолько молод, что окончательно не стандартизирован. Реализации стека IPv6 до сих пор остаются непротестированными в «промышленных» условиях. Значительная часть ошибок, обнаруживаемых в Linux и BSD, относится именно к IPv6. Старик Google по запросу «IPv6 Vulnerability» выдает около миллиона (!) ссылок. И хотя большинство дырок уже давно исправлено, окончательно вылизанный IPv6-стек мы получим лет через пять. В системах BSD/Linux. Что же касается Microsoft, то здесь очень трудно найти повод для оптимизма.

Самое неприятное, что от атак на IPv6 нельзя защититься брандмауэром/марштутизатором, поскольку брандмауэр/маршрутизатор, поддерживающий IPv6, сам по себе представляет объект для удаленных атак.
Внутри маршрутизатора

Большинство аппаратных марштутизаторов и брандмауэров (в том числе и CICSO) строятся на базе BSD-подобных операционных систем с минимальной адаптацией под конкретную архитектуру или даже без таковой. Чем же они тогда отличаются от обычного ПК с установленной Free/Net/OpenBSD? На ПК BSD еще поставить надо, железо правильное подобрать и еще программное обеспечение для управления всей этой системой написать. К тому же ПК содержит много лишнего. Зачем марштутизатору интегрированная видеокарта, AC3-звук и прочие компоненты? К тому же x86-процессоры — далеко не самое лучше средство для обработки сетевых пакетов. Но это, так сказать, сугубо техническая сторона вопроса. С точки же зрения безопасности, код, основанный на BSD, наследует все ошибки IPv6-стека, причем исправить их значительно труднее, чем в ПК-версии. Как минимум, потребуется дождаться заплатки от производителя маршрутизатора/брандмауэра, а потом «залить» ее внутрь «железки», если, конечно, в ней вообще предусматрена возможность обновления.

Выводы

Какую выгоду можно извлечь из IPv6-протокола? Первое, что приходит в голову: покупаем один IPv4-адрес и разворачиваем за ним огромную сеть с множеством IPv6-адресов, доступных благодаря туннельным протоколам из любой точки планеты. Даже из Антарктиды. Правда, с одной небольшой оговоркой — IPv6-адреса смогут увидеть лишь IPv6-клиенты, поддерживающие тот же самый тоннельный протокол, что установлен на нашем IPv4-/IPv6-узле. В настоящий момент таких узлов практически нет, и очень немногие пользователи согласятся совершать дополнительные телодвижения только затем, чтобы зайти на наш IPv6-сервер. Уж лучше «посадить» все серверы на один IPv4, используя виртуальные хосты, NAT'ы или другие подобные технологии.

В настоящий момент с IPv6 можно только «поиграться», но не более того. Практической отдачи — никакой, а вот проблем с безопасностью этот протокол создает немало. Поэтому лучше отключить поддержку IPv6, перекомпилировав ядро Linux/BSD. А что же на счет Windows Vista? Увы, полностью отключить поддержку IPv6 нельзя, и даже при выключенном IPv6 компоненты IPv6-стека будут по-прежнему принимать пакеты, что позволит атаковать систему. Хорошо хоть Teredo отключается штатными средствами. А IPv6 можно заблокировать на IPv4-брандмауэре, построенном на базе BSD с «вырезанным» IPv6-стеком.

Конечно, отказ от использования IPv6 – слишком радикальная мера защиты, но на данный момент она единственная. Все остальные решения — ненадежны.

Куда девался IPv5

Сначала у нас был IPv4, теперь все готовятся к неизбежному переходу на IPv6. А куда же подевался IPv5? Действительно, несправедливо делать вид, будто бы такого протокола и вовсе не существует. Известный под именем Streams 2 (ST2) и описанный в RFC 1819, он работает на том же уровне, что и IPv4, и используется (пусть и не очень широко) в приложениях реального времени.

Ключевые особенности протокола IPv6
Расширенные возможности адресации;
Упрощенный формат заголовка;
Изъятие из заголовка поля контрольной суммы;
Поддержка дополнительных заголовков;
Усиленные механизмы аутентификации;
Уменьшение размеров таблиц маршрутизации;
Возможность смены положения узла с сохранением его адреса.

Источник: itspecial.ru