Охота на сетевых партизан

Крис Касперски

Хакер, номер #111, стр. 111-150-1

Методы обнаружения (ре)трансляторов сетевых адресов и их клиентов

Внедрение безлимитных тарифов привело к появлению целой армии «партизан», скрывающихся за NAT/proxy-серверами и злостно уклоняющихся от исполнения своего воинского долга, то есть от абонентской платы. За одним IP-адресом могут прятаться десятки «уклоненцев», и, чтобы их прищемить, администратор должен выявить присутствие трансляторов сетевых адресов и/или proxy-серверов на клиентских узлах, используя доступное программное обеспечение.

Введение или против кого мы будем дружить

Прежде чем бороться, необходимо отчетливо себе представить, с кем (и с чем!) мы, собственно, боремся, иначе недолго и всех клиентов распугать. Компьютер уже давно не роскошь. У большинства пользователей дома по две-три машины, а то и больше (для себя, для брата, для жены). К интернету могут быть подключены ноутбук или даже DVD/CD/MP3 проигрыватель с Ethernet портом, которому выход в Сеть нужен не только для скачивания файлов, но и считывания названия песен из онлайновой базы. Не стоит забывать и про DRM – некоторые устройства требуют проверки аутентичности копии и без интернета не живут.

^{За одним NAT’ом может скрываться целый легион «партизан»}

Требовать от всех клиентов отдельного DSL-подключения на каждый компьютер не только не гуманно, но и технически невозможно — это сколько же телефонных линий нужно тянуть! Кроме того, некоторые DSL-модемы уже содержат встроенный NAT, который работает всегда, независимо от того, сколько узлов к нему подключено — восемь или один.

Наконец, не стоит забывать про виртуальные машины типа VM Ware или Virtual PC. Гостевым операционным системам тоже нужен выход в Сеть! А разные брандмауэры, баннеронарезалки, web-ускорители и прочие программы зачастую работают как proxy-сервер, даже если за ними сидит всего один пользователь!

Таким образом, само по себе наличие NAT'а или proxy-сервера на клиентской машине — еще не повод отрубать последнего от Сети (даже если их использование запрещено в договоре). Тут необходим комплексный анализ и тщательное расследование всех обстоятельств. В конце концов, существует тысячи способов «обуть» провайдера, не нарушив при этом договор. Скажем, получить заказы на скачку файлов по мылу и качать 24 часа в непрерывном режиме без всяких там proxy и NAT'ов, а сами скачанные файлы нарезать на DVD – не слишком удобно, зато честно.

«Правильные» провайдеры, обнаружив факт использования NAT'а, прежде всего смотрят на объем трафика и, если клиент реально «борзеет», пишут ему письмо с просьбой прокомментировать ситуацию. Быть может, это действительно небольшая домашняя сеть или аппетит у клиента такой. Ни о каких NAT'ах он не слышал, просто купил модем со встроенным транслятором. Так за что же его отрубать?!

Но довольно слов, перейдем к делу и опишем несложные и доступные методики обнаружения NAT'ов и proxy, которыми может воспользоваться каждый провайдер.

IP: TTL

Поле TTL (Time-to-Live – время жизни) в заголовке IP-пакета при прохождении через каждый узел уменьшается на единицу, включая узел, на котором расположен NAT. Следовательно, значение TTL пакетов, отправленных с NAT-сервера, окажется на единицу больше, чем значение TTL пакетов, отправленных остальными узлами, находящимися за NAT'ом. Это легко обнаруживается анализатором трафика.

Судя по форумам, некоторые провайдеры считают способ достаточно надежным, а хакеры, пытающиеся их обломать, пишут драйверы-фильтры, перехватывающие IP-пакеты и корректирующие значение TTL (но ведь драйвера еще необходимо уметь писать!). Намного проще указать начальное значение TTL в настройках TCP/IP стека, что по силам любому пользователю, взявшему в руки твикер.

IP: ID

Поле идентификатора IP-пакета, согласно RFC 791, должно быть уникально для IP-адреса узла-источника/узла-приемника, протокола, дейтаграммы, включая любой ее фрагмент, в течение срока жизни дейтаграммы в сети. И хотя нормативный документ не указывает пути достижения заданной уникальности, оставляя это на откуп конкретным реализациям TCP/IP стека, все современные ОСи (Linux, BSD и Windows, начиная с Win2k) просто генерируют некоторое число, а потом увеличивают его с каждым посланным пакетом на единицу. В результате чего мы получаем простую последовательность, конечно, при условии, что с данным узлом ассоциирована только одна машина. Две машины, находящиеся за NAT'ом, сгенерируют две последовательности, а если счет машин идет на десятки, то провайдер видит в идентификаторах рандомный мусор, что дает ему все основания прищемить пользователя, крышующего партизан.

^{Пример топологии корпоративной сети}

Теоретически можно написать драйвер-фильтр, корректирующий идентификаторы всех уходящих пакетов, но… он должен быть запущен на машине с NAT-сервером. Если же «злоумышленник» использует DSL-модем с кучей Ethernet-портов, ему придется не по-детски извратиться, чтобы запустить драйвера-фильтры на всех партизанских машинах. В этом случае некоторые NAT'ы могут поехать крышей, отказавшись функционировать, да и сложность разработки подобного драйвера соответствующая.

Кажется, что анализ идентификаторов IP-пакетов идеально подходит для выявления партизан, но, увы – Windows 9x, Me, NT используют различные алгоритмы генерации IP-идентификатора, и скрипты, написанные администраторами, зачастую ошибочно принимают их за толпу партизан. Конечно, Win9x сегодня большая редкость, и основная масса народа сидит под XP, однако, это еще не повод, чтобы рубить с плеча. Как уже говорилось выше, прежде чем отрубать клиенту доступ в Сеть, необходимо на 100% быть уверенным, что он действительно нарушил хотя бы один пункт договора, иначе однажды можно нарваться на типа, конкретно знающего законы. По судам затаскает — не отмажешься!

TCP/UDP – диапазон портов источника

Поскольку 99,9% приложений, работающих с Сетью, предоставляют операционной системе право самостоятельного назначения порта источника (из числа свободных), то выбирая номера портов определенным образом, можно спрятать за одним IP-адресом очень много узлов. Идея NAT'ов как раз и основана на том, что они обеспечивают уникальность связки IP-источник: порт-источника -> IP-приемник: порт-приемника, «отлавливая» пакеты, поступающие с разных внутренних узлов, на один внешний узел за счет «маппинга» номеров портов источника, и никой путаницы «чей пакет?» не возникает.

Однако большинство NAT'ов использует фиксированный диапазон портов для «маппинга», который намного уже диапазона портов, назначаемых операционной системой. Поэтому, если у провайдера имеется достаточное количество клиентского трафика и этот трафик сосредоточен в узком диапазоне портов отправителя, то можно предположить, что тут замешан NAT.

Методика считается очень надежной, хотя и ей присущи свои недостатки. Начнем с того, что NAT'ы бывают встроены не только в DSL-модемы с Ethernet-портами, но даже в модемы, подключаемые по USB! То есть узкий диапазон портов указывает на наличие транслятора, и ничего не говорит о том, сколько пользователей за ним сидит: один или несколько (поле TTL при всей его незатейливости подобных ложных срабатываний не допускает).

Далее. Если на машине, генерирующей большое количество трафика, установлен программный NAT, провайдер получит более или менее нормальное распределение по портам, и ему нужно будет очень-очень долго собирать трафик, чтобы заподозрить, что тут что-то не так. С другой стороны, некоторые приложения (например, клиенты файлообменных сетей) поддерживают настройку диапазона используемых портов источника, что с точки зрения провайдера выглядит как наличие NAT'а. Очередная ложная тревога! Так что пользоваться этой методикой следует крайне осторожно.

Прикладной уровень – в охоте за реальными IP

А как определить реальный IP-клиента, раз NAT автоматически подменяет его во всех IP-пакетах? Действительно, на IP-уровне нам ловить нечего, но вот если подняться на уровень прикладных протоколов, можно обнаружить, что многие программы внедряют IP-адреса в «свои» пакеты. Так поступают, в частности, некоторые почтовые клиенты, instant messenger'ы (MSN, ICQ) и другие «товарищи», на которых партизаны палятся как молодые.

Народ поумнее юзает открытый софт, который ничего и никуда не вставляет — с этой проблемой там разобрались уже давно. К тому же, если у компьютера имеется несколько интерфейсов (локальная сеть, сотовый телефон, периодически работающий как GPRS модем, WiFi-адаптер), то независимо от наличия/отсутствия NAT'а или proxy клиентские приложения очень часто ошибаются с определением «настоящего» IP, потому как понятие «настоящего» IP абсурдно и применимо лишь к узлам, имеющим всего один сетевой интерфейс. Компьютеры, обладающие несколькими интерфейсами, имеют более одного IP, и все они «настоящие». А таблица маршрутизации — штука сложная и несовершенная. Windows вполне может попытаться послать пакет, адресованный внешнему узлу, на беспроводной адаптер домашней локалки, и только убедившись, что он ни хвоста не маршрутизируется, попытать счастья на другом интерфейсе.

^{DSL-модем с несколькими Ethernet-портами и встроенным (причем, неотключаемым) NAT’ом на борту}

Если приложение определяет «свой» IP уже после установки соединения, то все ОК, но ведь не все приложения такие правильные. Многие из них запрашивают у операционной системы список сетевых интерфейсов до установки соединения и в качестве «настоящего» IP берут адрес первого интерфейса, а поскольку таблица маршрутизации может меняться при подключении/отключении сетевых устройств, вместе с ней будет меняться и «настоящий» IP. И все это на компьютере, за которым сидит всего один пользователь! Ложная тревога… ну сколько же можно?! Увы, против современных технологий не попрешь!

Proxy-сервера

Подавляющее большинство proxy-серверов явно прописывает свое присутствие в HTTP-запросах и обнаружить их — не проблема, однако многие пользователи устанавливают proxy-сервер не только для совместного доступа интернет-соединения, но и для кэширования запросов. Горящий Лис, Опера и IE кэшировать тоже умеют, но далеко не так хорошо, как это делают некоторые proxy-серверы, которые, к тому же, ведут статистику, отображая ее в наглядной графической форме. А если клиент попеременно использует несколько браузеров, то для экономии трафика и дискового пространства разумнее всего «запитать» все браузеры от одного proxy-сервера, запретив им самостоятельное кэширование страниц.

Ладно, предположим, что proxy-сервер скрывает факт своего присутствия. Может ли провайдер его обнаружить? Сканирование портов — метод простой, но… Если пользователь не полный лох, то: а) повесит proxy на нестандартный порт; б) повесит proxy на интерфейс обратной петли; в) запретит подключение со всех IP-адресов, кроме локальных. И хотя продвинутые сканеры портов (типа nmap) все-таки обнаружат присутствие закрытого порта, определить его назначение они ни за что не смогут (если, конечно, proxy-сервер при попытке подключения с внешних адресов не выдает страничку со злобной надписью «access denied»).

Другими словами, тщательно замаскированный proxy-сервер, обслуживающий закрытую сеть, со стороны провайдера обнаружить невозможно. Все методики либо ненадежны, либо выдают огромное количество ложных позитивных срабатываний, реагируя на различные утилиты, устроенные по принципу proxy-серверов.

Заключение

В идеале провайдер вообще не должен ограничивать свободу клиентов, а если и ограничивать, то в разумных пределах. Провайдер, ставящий клиента в позу и не позволяющий ему разделить трафик с женой, братом, виртуальной машиной и собачкой Жучкой, никому не интересен, и к нему идут только ламоты, не читающие договора и не думающие, что они будут делать, если захотят установить VM Ware или протянуть в квартире локальную сеть. К тому же закон о защите потребителей никто не отменял, и суды чаще всего выносят решения именно в пользу обиженных пользователей.

С другой стороны, бороться с партизанами все-таки надо, особенно если внутрисетевой трафик дешевле грязи или вообще не тарифицируется. Тогда к держателю NAT'а могут подключаться соседи по лестничной площадке, а это приличная недостача для казны провайдера.

Как мы уже убедились, ни одна методика обнаружения NAT'ов не обходится без изъяна, и никакую из них по отдельности применять нельзя. Но вот совокупность всех описанных методик дает неплохой результат, вполне пригодный для обнаружения нарушителей.

А если сюда подключить еще и психологию, то количество ложных срабатываний вообще упадет до нуля. Как, наверняка, известно опытным провайдерам, практически каждый пользователь, дорвавшийся до безлимитки, проходит через три стадии. Сначала качает все-все-все, не выключая компьютер ни ночью, ни днем. Затем интерес начинает потихоньку спадать. Пользователь становится более разборчивым и уже не льет всякую дрянь (потому как свободное дисковое пространство уменьшается со страшной скоростью, а болванки стоят денег). Наконец, пользователь окончательно успокаивается, и потребление трафика значительно сокращается. В противном случае подозрения, что пользователь не один, резко усиливаются (хотя встречаются и такие типы, которые не успокаиваются и через год). Так что некоторая неоднозначность все-таки остается…

INFO

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

WWW

Основная информация о NAT'ах:

• http://en.wikipedia.org/wiki/Network_address_translation

Как обнаружить использование NAT?

• http://forum.swamp.ru/viewtopic.php?t=75236

Хакерские методики сокрытия NAT'ов от провайдера:

• http://www.xakep.ru/post/29448/default.asp?page=2

ВИДЕО К ЭТОМУ НОМЕРУ