Перенаправление траффика на удаленный сниффер средствами iptables+iproute2

После покупки своего первого смартфона люди обычно замечают, что расходы на мобильную связь немного увеличиваются. Обычно это происходит за-за того, что «умный» телефон «ходит в Сеть» без ведома хозяина. Конечно, решить эту проблему просто — установить специальные утилиты для блокирования подключений к точкам доступа GPRS/HSDPA либо купить безлимитный тариф на доступ в Интернет и забыть. Столкнувшись с описанной ситуацией, я в первую очередь заинтересовался и тем, что телефон ищет в Сети и, самое главное, что передает в Сеть. Последнее особенно актуально в связи с недавними новостями.

Для просмотра траффика, который смартфон отправляет в Сеть, понадобится специальная программа — сниффер.
Иногда ее можно просто установить на телефон. Это самый надежный способ, но он не всегда доступен.
Если на смартфоне есть Wi-Fi, то можно использовать дополнительные устройства — например, подключить его через Wi-Fi к роутеру или компьютеру со сниффером, или, если нет доступа к роутеру с Wi-Fi, подключить его к незащищенной Wi-Fi сети и анализировать весь траффик с третьего компьютера.

Рассмотрим самый типичный случай — домашнюю сеть, управляемую обычной точкой доступа с Wi-Fi (DSL-модем или роутер), параметры которой менять не хочется. Большинство домашних точек доступа работает под управлением Linux, к которому можно без проблем получить доступ, например, через telnet.
Данная заметка расскажет, как перенаправить весь траффик со смартфона (или вообще с любого другого хоста сети) на компьютер с Linux для изучения так, чтобы для исследуемого устройства это было незаметно.

Здесь не описываются принципы работы Netfilter или iproute2. Эту информацию легко найти в Интернет — в конце заметки есть ссылки, где можно об этом прочитать. Приведен всего лишь еще один способ элегантного применения этих средств, который, надеюсь, даст возможность почувствовать всю их мощь и простоту.


Итого мы имеем:

1. Сеть с роутером на Linux и доступным на нем shell (например, для моего случая — модема от Стрима получение доступа описано здесь). IP-адрес в сети: 192.168.1.1.
2. Компьютер с любым дистрибуивом Linux. Почему Linux? Да потому что практически все дистрибутивы Linux включают в себя утилиты iptables и iproute2 и сниффер tcpdump, с помощью которых можно решать почти все сетевые задачи. Но сниффером лучше пользоваться с GUI. Например, Wireshark. IP-адрес: 192.168.1.2.
3. Собственно, исследуемое устройство — смартфон, подключенный к нашей сети. IP-адрес: 192.168.1.3.

План действий простой: используя iproute2, создаем на роутере отдельную таблицу маршрутизации и правило, которое будет использовать ее для всего траффика со смартфона. Укажем в таблице шлюз по умолчанию — хост со сниффером:

# Выполнять на роутере
ROUTER=192.168.1.1
SLEUTH=192.168.1.2
SUSPECT=192.168.1.3
TABLE=14
ip rule add from $SUSPECT table $TABLE priority 5
ip route add default via $SLEUTH table $TABLE

Важно! Не допускается два правила с одинаковым приоритетом. Сначала нужно проверить, нет ли другого правила с таким же приоритетом: ip rule list

Число для priority желательно выбрать поменьше — чем меньше значение, тем выше приоритет. У меня первые четыре были заняты.
Таблицу ($TABLE) можно выбрать любую неиспользуемую. Используется ли таблица, можно посмотреть с помощью команды ip route list table $TABLE.

Хост со сниффером должен перенаправлять весь исследуемый траффик в Сеть. С этим легко справится NAT. Далее этот траффик легко пройдет через все тот же роутер и отправится по назначению — ведь теперь у IP-пакетов другой адрес отправителя и в нашу таблицу маршрутизации он не попадет:

# Выполнять на сниффере
ROUTER=192.168.1.1
SLEUTH=192.168.1.2
SUSPECT=192.168.1.3

sysctl -w net.ipv4.ip_forward="1"
iptables -I FORWARD -s $SUSPECT -j ACCEPT
iptables -I FORWARD -d $SUSPECT -j ACCEPT
iptables -t nat -I POSTROUTING -s $SUSPECT -j MASQUERADE

Вот, казалось бы, и всё. Можно запускать на компьютере сниффер и фильтровать траффик по IP-адресу 192.168.1.3.

Но у такой схемы есть существенный недостаток: на сниффер не попадет траффик, который предназначался самому роутеру. Например, DNS. Иногда, это важно, например, чтобы определить, что за сервер 74.125.39.188 (mtalk.google.com), на которых смартфон непрерывно что-то шлет. Для этого снова используем iptables. Судя по схеме из руководства по iptables, чтобы в результате маршрутизации этот траффик был перенаправлен (попал в правую ветвь), нужно изменить его адрес назначения в PREROTING:

# Выполнять на роутере
iptables -t nat -I PREROUTING -s $SUSPECT -d $ROUTER -j DNAT --to-destination $SLEUTH

Команды, настраивающие перенаправление (таблицу FORWARD), пропустим — ведь на роутере оно уже должно работать в штатном режиме :)

На хосте-сниффере меняем адрес назначения назад:

# Выполнять на сниффере
iptables -t nat -I PREROUTING -s $SUSPECT -d $SLEUTH -j DNAT --to-destination $ROUTER

Надо заметить, что на хосте-сниффере траффик попадет под маскарадинг (MASQUERADE), то есть у пакетов адрес источника тоже поменяется. В итоге пакеты должны перемещаться по следующей схеме (над стрелками указаны номера хостов отправителя и получателя пакета, последовательность — сверху вниз):



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


Выход из сложившейся ситуации прост — снова направить эти пакеты на роутер, аналогично тому, как было сделано перенаправление на сниффер:

# Выполнять на сниффере
TABLE=15
ip rule add to $SUSPECT table $TABLE priority 7
ip route add default via $ROUTER table $TABLE

Получая данный «проблемный» траффик, Netfilter роутера с помощью механизма определения состояний (модуля nf_conntrack), «узнаёт» в нем соединения, измененные с помощью DNAT и заменяет адрес получателя пакетов на исходный. Далее пакеты отправляется получателю как ни в чем не бывало.

Окончательный вариант скриптов:

# Выполнять на роутере
ROUTER=192.168.1.1
SLEUTH=192.168.1.2
SUSPECT=192.168.1.3

TABLE=14
ip rule add from $SUSPECT table $TABLE priority 4
ip route add default via $SLEUTH table $TABLE

iptables -t nat -I PREROUTING -s $SUSPECT -d $ROUTER -j DNAT --to-destination $SLEUTH

# Выполнять на сниффере
ROUTER=192.168.1.1
SLEUTH=192.168.1.2
SUSPECT=192.168.1.3

sysctl -w net.ipv4.ip_forward="1"

iptables -I FORWARD -s $SUSPECT -j ACCEPT
iptables -I FORWARD -d $SUSPECT -j ACCEPT
iptables -t nat -I POSTROUTING -s $SUSPECT -j MASQUERADE
iptables -t nat -I PREROUTING -s $SUSPECT -d $SLEUTH -j DNAT --to-destination $ROUTER

TABLE=15
ip rule add to $SUSPECT table $TABLE priority 5
ip route add default via $ROUTER table $TABLE

Примечания

1. И на роутере, и на компьютере должны быть установлены пакеты iptables, iproute2, а в ядро должна быть включена поддержка netfilter и advanced routing. В большинстве дистрибутивов и в большинстве роутеров выполнено и то, и другое. Если ядро было сконфигурировано самостоятельно, то лучше перепроверить их наличие.
2. Роутер, хост-сниффер и телефон могут находиться в разных сегментах сети. Главное, чтобы они были связаны, и весь траффик со смартфона проходил через роутер.
3. В качестве смартфона в этой заметке может выступать любое другое устройство, способное выходить в Интрнет через Wi-Fi или Ethernet.
4. Применение описанного метода для сбора и распространения конфиденциальной информации а также частной информации о жизни лица без его согласия НЕЗАКОННО! (Статьи 137, 138 УК РФ)
5. Помните, что даже защищенные Wi-Fi сети могут быть небезопасными, если вы не уверены в том, что точка доступа полностью защищена от вмешательства посторонних лиц. Если это важно, используйте протоколы передачи данных, поддерживающие шифрование, например, HTTPS, XMPP (Jabber).
6. Конечно же применение данного метода по отношению к компьютеру с полноценной ОС легко отслеживается и с помощью tracroute (tracert в Windows), или просто из-за уменьшения TTL пакетов, что заметно при пинге роутера.

Ссылки

1. Linux Advanced Routing & Traffic Control HOWTO (рус.)
2. Руководство по iptables (Iptables Tutorial 1.1.19)