[BlackRat]

.....

Механизм шифрования, используемый Skype

Skype-клиенты крайне деликатно обходятся с брандмауэрами и трансляторами сетевых адресов, просачиваясь сквозь них через хорошо известные протоколы STUN и TURN. Протокол STUN уже вошел в Библию Интернета и подробно описан в RFC-3489. Что же касается TURN'а, то он все еще находится в разработке и в настоящее время доступна лишь черновая версия стандарта: www.jdrosen.net/midcom_turn.html.

Так что, с юридической точки зрения, действия Skype законны и не попадают под статью. STUN, расшифровывающийся как Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (простое проникновение датаграмм протокола UDP через транслятор сетевых адресов (NAT)), представляет собой отличное средство, которое страдает, однако, рядом ограничений и не работает в следующих случаях:

если путь во внешнюю сеть прегражден злобным брандмауэром, режущим весь UDP;
если на пути во внешнюю сеть стоит симметричный транслятор сетевых адресов.
Ну, с брандмауэром все понятно. Если UDP закрыт, то никак его не откроешь. А вот симметричный транслятор сетевых адресов (symmetric NAT) — это что за штука? Не углубляясь в технические детали, скажем, что симметричный NAT представляет собой разновидность обыкновенного транслятора, требующего, чтобы целевой IP-адрес и порт транслируемого пакета совпадали с внешним (external) IP-адресом и портом. Если один и тот же узел посылает пакеты с одинаковыми исходными IP-адресами и портами по разным направлениям, NAT будет вынужден транслировать их на другие порты. Таким образом, чтобы отправить внутреннему узлу UDP-пакет, внешний узел должен первым делом получить запрос от внутреннего узла. Самостоятельно инициировать соединение внешний узел не в состоянии, поскольку NAT просто не знает, на какой внутренний IP и порт следует транслировать неожиданно сваливавшийся UDP-пакет.

Эта проблема решается протоколом TURN (Traversal Using Relay NAT), технические подробности работы которого описаны по вышеупомянутому адресу и большинству читателей совершенно неинтересны. Гораздо важнее другое — протокол TURN значительно увеличивает латентность и теряет большое количество UDP-пакетов (packet loss), что далеко не лучшим образом сказывается на качестве и устойчивости связи, но полное отсутствие связи - еще хуже. Так что пользователям Skype стоит радоваться, а не жаловаться!


Структура Skype-сети, в которой присутствуют Skype-клиенты за NAT и брандмауэрами

Вот только администраторы этой радости почему-то не разделяют, наглухо закрывая UDP-трафик (тем более что большинству нормальных программ он не нужен). Немного поворчав для приличия (замуровали, демоны!), Skype автоматически переключается на чистый TCP, отрубить который администратору никто не позволит. Правда, поколдовав над брандмауэром, тот может закрыть все неиспользуемые порты, но в том-то и подвох, что неиспользуемых портов в природе не встречается! При соединении с удаленным узлом операционная система назначает клиенту любой свободный TCP/UDP-порт, на который будут приходить пакеты. То есть, если мы подключаемся к web-серверу по 80-му порту, наш локальный порт может оказаться 1369-м, 6927-м или еще каким-нибудь другим. Закрыв все порты, мы лишимся возможности устанавливать TCP/UDP-соединения!

Единственный выход — обрубить всем пользователям локальной сети прямой доступ в интернет, заставив их ходить через proxy-сервер. Однако даже такие драконовские меры не решат проблемы, поскольку Skype просто прочитает конфигурацию браузера и воспользуется proxy-сервером как своим родным!


Skype, работающий через proxy-сервер, конфигурация которого прочитана из настроек браузера

Как заблокировать Skype-трафик
Разработчики Skype предостерегают администраторов от попыток выявления и блокирования его трафика (типа: «Все равно у вас ничего не получится!»). И действительно, распознать Skype-трафик очень сложно, а заблокировать его можно только по содержимому, которое зашифровано и не содержит никаких предсказуемых последовательностей. К счастью для администраторов, создатели Skype, при всей своей гениальности, допустили ряд оплошностей, оставив часть трафика незашифрованной. UDP-соединение использует открытый протокол для получения публичных IP-адресов super-узлов, что вполне может быть выявлено анализатором трафика. Это раз. TCP-соединение использует один и тот же RC4-поток дважды, что позволяет нам восстановить 10 первых байт ключа, расшифровав часть постоянных полей заголовков Skype-протокола. Это два! Кстати, весьма полезная вещь для шпионажа за чужими разговорами! Однако мне не известен ни один готовый блокиратор Skype-трафика, а писать свой собственный — лениво, да и времени нет.


Повторное использование RC4-потока позволяет восстановить 10 байт ключа из 12-ти, расшифровывая часть Skype-трафика

Распознать и заблокировать UDP-трафик намного проще. Каждый фрейм начинается с двухбайтового идентификационного номера (ID) и типа пакета (payload). В UDP-пакет вложен 39-байтный NACK-пакет, пропущенный через обфускатор и содержащий следующие данные:

идентификатор пакета (непостоянен и варьируется от пакета к пакету);
номер функции (func), пропущенный через обфускатор, но func & 8Fh всегда равно 7h;
IP отправителя;
IP получателя.
Таким образом, чтобы заблокировать UDP-трафик, генерируемый Skype, достаточно добавить в брандмауэр следующее правило:

iptables -I FORWARD -p udp -m length --length 39 -m u32
--u32 '27&0 x8f=7' --u32 '31=0 x527c4833 ' -j DROP