рекогносцировка на небоскребе

КРИС КАСПЕРСКИ

Спецвыпуск: Хакер, номер #072, стр. 072-058-2

Большинству сегодняшних пользователей IPv6 совершенно не нужен, поскольку для локальной сети и IPv4 хватает с лихвой, а основная масса провайдеров еще не поддерживает IPv6 и в обозримом будущем переходить на него не собирается. Проблема в том, что IPv6 несет в себе множество нововведений, еще не обкатанных и не протестированных в планетарном масштабе. Это настоящий кот в мешке, от которого можно ожидать чего угодно. Новых проблем, новых атак…

Теоретически (и только теоретически!) IPv6 обеспечивает более высокую производительность и лучшую защиту от атак, но практически вопросы производительности решаются «тонкой» настройкой опций TCP-/IP-протокола, которые в Windows доступны лишь частично, и крайне отрывочно «документированы» в виде заметок в Knowledge Base. TCP-/IP-протокол - это не трактор — сел, завел и поехал. Над ним еще поколдовать нужно, учитывая ширину канала, характер запросов и так далее.

Настойки по умолчанию стремятся удовлетворить сразу всех и каждого, в результате чего по-настоящему не остается удовлетворен никто. Отсутствие легальных рычагов управления не позволяет оценивать реальную производительность сетевого стека, и громкие заявления Microsoft'а, что в Висте стек намного более производителен, следует расценивать как пропаганду. Результаты тестов ни о чем не говорят! Откуда мы знаем, может Microsoft просто подкрутила настойки, чтобы Виста выдавала лучше результаты при испытаниях на заранее подготовленном полигоне?! Тем более что в большинстве случаев реальный CPS определяется отнюдь не «качеством» сетевого стека, а загруженностью удаленного сервера, пропускной способностью каналов связи и так далее. Глупо ожидать, что, установив Висту на свой компьютер, мы «разгоним» свой модем хотя бы на десяток процентов...

[хакеры штурмуют тоннели.]

Следствием интеграции IPv4 с IPv6 в единый сетевой стек стало появление туннельных протоколов Teredo, ISATAP, 6to4 и 6over4, причем Teredo уже успел попасть в RFC и осесть под номером 4380 (http://www.rfc-editor.org/rfc/rfc4380.txt). Разжеванное описание на понятном даже для неспециалистов языке можно найти в статье «Teredo Overview», опубликованной на Microsoft Tech Net: www.microsoft.com/technet/prodtechnol/winxppro/maintain/teredo.mspx.

Говоря на пальцах (сурдоперевод для глухонемых), Teredo инкапсулирует (упаковывает) IPv6-трафик внутрь IPv4-пакетов (см. рисунок 3), используя протокол UDP, слабости и недостатки которого хорошо известны. Если два IPv6-узла разделены IPv4-сегментом сети (наиболее типичная на сегодняшний день конфигурация), Виста задействует Teredo, направляя запрос одному из публичных Teredo-серверов, который, в свою очередь, передает его получателю, фактически выполняя роль proxy-сервера.

Самое интересное, что Teredo позволяет обходить трансляторы сетевых адресов (они же NAT'ы) и брандмауэры, причем это не баг, а фича. Рассмотрим два узла, защищенные NAT'ом, прямое взаимодействие между которыми невозможно. Но это оно по IPv4 невозможно, а если использовать Teredo-тоннель, то истинный адрес и порт назначения окажется скрыт в Teredo-заголовке, а в IPv4 попадает адрес узла, «смотрящего» в интернет и UDP-порт самого Teredo (3544), который, конечно, можно и закрыть, но как же тогда с остальными Виста-клиентами общаться?! Поскольку NAT не может установить ни реального целевого адреса, ни реального целевого порта протокола IPv6, он беспрепятственно пропускает IPv4-пакет. Это же самое относится и к другим защитным механизмам, не поддерживающим протокола Teredo.