- Регистрация
- 03.06.2012
- Сообщения
- 6 194
- Репутация
Хе у меня достаточно мощный роутер, решил сделать "публичный WiFi", который доступен в пределах моего двора.
Да, знаю многие заморачиваются (да, я и сам раньше) защитой своей точки, что-бы никто неподключился.
Но мне стало интересно, сколько подключится ко мне. Да все желающие могут бесплатно подцепиться.
Но потом мне стало интересно, а на сколько безопасно это в РФ ? Ведь чисто теоретически, если кто-то подключится и начнёт, каким-то криминалом заниматься, по хорошему могут потом ко мне прийти.
По началу, думал весь трафик загнать через прокси, но сегодня даже случайно попалась статейка на Хакере (Пока-что непробовал), загнать весь трафик в ТОР.
В этой статье рассмотрим, как конфигурировать точку доступа Wi-Fi с автоматической анонимизацией всего исходящего трафика через сеть Tor, а также взглянем на некоторые полезные примеры ее применения как для простого пользователя, так и для исследователя безопасности.
Зачем нам Tor AP?
В последнее время на фоне массовых блокировок IP-адресов все меньше людей продолжает сомневаться, нужны ли механизмы проксирования и анонимизации в их повседневной жизни. Бесплатных VPN-клиентов появляется все больше, но, как
Как известно, Tor «из коробки» предоставляет как механизм проксирования (читай: обхода блокировок), так и продвинутый механизм анонимности. Вся связь между узлами в сети Tor шифруется, а соединение с целевым узлом устанавливается посредством как минимум трех случайно выбранных узлов. Взяв за основу Tor и автоматизировав все процессы, происходящие при подключении к точке доступа (далее — AP), в результате мы получим весьма интересный инструмент, польза от которого отнюдь не исчерпывается обходом блокировок.
Первичная настройка AP
Для создания точки нам понадобится какое-нибудь устройство, на котором можно запустить операционку (виртуалка тоже вполне сгодится). В качестве операционной системы, управляющей точкой, подойдет любой Linux-дистрибутив. Конкретно я буду использовать Debian-based. Для превращения всего этого в AP понадобится Wi-Fi-адаптер.
Если все это выполнено, можно приступать к первичной настройке. Итак, в первую очередь подключаем Wi-Fi-адаптер. Вывод ip addr show wlan0 (wlan0 — имя интерфейса адаптера, может быть другим) должен быть такой, как на скрине.
Детали сетевого интерфейса адаптера
На данный момент сетевой интерфейс не сконфигурирован. Первым делом активируем Wi-Fi, освободив его от влияния вездесущего Network Manager’а:
$ sudo nmcli radio wifi off
$ sudo rfkill unblock wlan
Теперь выберем и назначим интерфейсу адаптера IP-адрес, все адреса из
маски которого будут назначаться в дальнейшем клиентским устройствам:
# ip addr add 10.0.0.1/24 dev wlan0
Третьим пунктом мы переведем адаптер в режим AP: делать это мы будем одним из наиболее распространенных способов — с помощью утилиты
$ sudo apt-get install hostapd
Далее нужно создать конфиг для hostapd (./hostapd.conf):
## Имя интерфейса адаптера
interface=wlan0
## SSID AP
ssid=TorNet
## Автоматический выбор канала
channel=1
## Разрешить подключение со всех MAC-адресов, которые не запрещены
macaddr_acl=0
## Файл с запрещенными для подключения MAC-адресами
deny_mac_file=./denied_macs
## Логировать все модули (IEEE, WPA, IAPP и так далее)
logger_syslog=-1
## Логировать с модулей только informational messages
logger_syslog_level=2
## Режим: IEEE 802.11g
hw_mode=g
## Включить аутентификацию WPA/2
wpa=2
## Пароль WPA для доступа к точке
wpa_passphrase=xxxxxxxx
## Принимаемые алгоритмы управления ключами
wpa_key_mgmt=WPA-PSK WPA-EAP WPA-PSK-SHA256 WPA-EAP-SHA256
После этого уже можно будет запустить hostapd для перевода Wi-Fi-адаптера в режим AP с описанной конфигурацией:
# hostapd ./hostapd.conf
Hostapd и Network Manager
В некоторых версиях hostapd присутствует баг, связанный с блокировкой интерфейса Network Manager’ом и не позволяющий запускать AP. В
результате запуска hostapd возникает следующая ошибка:
Interface wlan0 wasn't started
Подробно баг и возможный воркэраунд описан
Однако по понятным причинам подключиться к точке привычным образом пока будет невозможно.
Попытка подключения к AP без DHCP
Для устранения этих причин понадобится другая утилита — dnsmasq, которая позволит развернуть службы DHCP и DNS. DHCP сейчас представляет больший интерес.
Ставим dnsmasq из стандартного репозитория:
$ sudo apt-get install dnsmasq
Dnsmasq также нуждается в предварительной настройке (./dnsmasq.conf):
## Интерфейс для прослушки DHCP-запросов
interface=wlan0
## Диапазон выдаваемых клиентам адресов и срок действия
## (должны подходить под маску сетевого шлюза адаптера!)
dhcp-range=10.0.0.10,10.0.0.250,8h
## Шлюз по умолчанию
dhcp-option=3,10.0.0.1
## DNS-шлюз
dhcp-option=6,10.0.0.1
## Логировать DNS-запросы
log-queries
## Логировать DHCP-запросы
log-dhcp
Запускаем DHCP-сервер в составе dnsmasq:
# dnsmasq -C ./dnsmasq.conf
Теперь подключение к AP становится возможным с любых устройств. Чтобы наша точка наконец заработала в обычном режиме, осталось ответить на главный вопрос: откуда точка будет брать доступ в интернет. Для получения ответа предлагаю взглянуть на схему ниже. Большинство читателей, так или иначе соприкасавшихся с настройкой сетей, заметят на нем достаточно привычную схему связывания сетей. Именно этот способ мы и будем использовать.
Схема доступа в интернет с AP
Как видно из рисунка, для доступа в интернет понадобится еще один сетевой интерфейс. Это может быть как Ethernet-подключение (eth0), так и второй Wi-Fi-модуль (wlan1).
Например, при создании AP из виртуальной машины такой интерфейс создается автоматически (eth0). Сейчас у нас готово все, за исключением связи между интерфейсами (обозначенной красной линией).
Эта связь представляет собой пересылку пакетов с одного интерфейса на другой. Для тестирования работоспособности нашей AP пока
сгодится и обычный механизм NAT:
$ sudo sysctl -w net.ipv4.ip_forward=1
$ sudo iptables -P FORWARD ACCEPT
$ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
На данном этапе AP заработала в обычном режиме: принимает клиентов и предоставляет им доступ в интернет с IP-адреса, выданного нам нашим
провайдером. Это, конечно же, замечательно, но для наших целей недостаточно. Поэтому теперь настало время перенаправления всего
клиентского трафика в Tor.
Вторичная настройка AP
Перед перенаправлением всего трафика AP в Tor необходимо установить сам Tor:
$ sudo apt-get install tor
И настроить его как Transparent Proxy с помощью конфигурационного файла (расположенного здесь: /etc/tor/torrc):
## Включаем доступ к onion-ресурсам
VirtualAddrNetwork 192.168.100.0/10
AutomapHostsOnResolve 1
## Порт для прозрачного проксирования в рамках нашей сети
TransPort 10.0.0.1:9040
## Порт для анонимного резолвинга имен хостов
DNSPort 10.0.0.1:53
Этих настроек для наших нужд вполне достаточно, поэтому можем запускать Tor как сервис:
$ sudo service tor start
На текущий момент вывод netstat -tunapl должен быть примерно таким, как на скрине ниже. Мы видим все запущенные нами сервисы на текущий момент.
Открытые порты на AP
Если сейчас подключиться к AP, то мы по-прежнему будем выходить в интернет с домашнего IP, поэтому осталось всего-навсего включить проксирование через Tor с помощью iptables:
# Перенаправление всего TCP-трафика
$ sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp -j DNAT --to-destination 10.0.0.1:9040
# ...и DNS-трафика в отдельности
$ sudo iptables -t nat -A PREROUTING -i wlan0 -p udp --dport 53 -j DNAT --to-destination 10.0.0.1:53
Также нужно удалить предыдущее правило, включающее маскарад между сетевыми интерфейсами (NAT):
$ sudo iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
Двумя новыми правилами мы добились следующего: подмены пункта назначения всего TCP-трафика в момент появления пакетов на сетевом интерфейсе Wi-Fi-адаптера и редиректа DNS-запросов (протокол UDP).
Подмененный пункт назначения — запущенный сервис Tor с Transparent Proxy. Стоит обратить внимание, что на этих двух правилах настройка iptables завершается. Теперь можно убедиться в работоспособности настроенной Tor AP, посетив с любого подключенного к ней устройства 2ip.ru.
PoC
RPi как AP
«Малинка» отлично подходит в качестве управляющего устройства AP: всего несколько дополнительных действий с автоматической разверткой конфигурации при старте системы (systemd, initV), и останется всего лишь воткнуть USB-кабель в «розетку» для включения точки в любой нужный момент.
Практическое применение AP
Имея собственную AP, с которой соединяются клиентские устройства, мы по умолчанию получаем возможность наблюдения за всем трафиком своей сети, как пассивного, так и активного. Перенаправление в Tor — это лишь один из вариантов применения AP в прикладных задачах.
Анализ трафика клиентских устройств
Пожалуй, самый очевидный вариант, который сразу же приходит в голову.
Никто не запрещает запустить на AP Wireshark или tcpdump и захватывать трафик конкретного клиента либо всех клиентских устройств сразу до момента перенаправления трафика в Tor.
Возможности для захвата здесь ограничены лишь уровнем защищенности конечного устройства, пользователя и приложения. Тема достаточно известная, поэтому подробно на ней останавливаться не будем.
Захват трафика по MAC-адресу на AP
Анализ сетевой активности приложений
В ИБ часто возникает задача проанализировать сетевую активность определенного приложения. Например, у нас имеется мобильное приложение, которое при работе использует несколько известных нам хостов. Мы хотим методом черного ящика проверить, не ведет ли приложение какие-либо скрытые передачи на дополнительные удаленные хосты.
Причем на самом устройстве мы это сделать не можем — нет соответствующих прав на уровне ОС. Зато у нас есть AP, находящаяся полностью под контролем и с максимальными правами! Ее использование будет практически аналогично анализу трафика на целевом устройстве.
Попробуем исследовать работоспособность приложения без скрытого доступа к каким-либо дополнительным ресурсам. Заранее мы отключили все остальные источники побочного трафика, генерируемого из других приложений. Скрытые передачи в данном случае не обязательно должны быть вредоносными — это могут быть механизмы антиспама (контроль того, что API приложения действительно используется с мобильного устройства), рекламы и так далее. Мы можем пропускать трафик методом белого ящика — запрещено все, что не разрешено:
$ sudo iptables -t nat -F
$ sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp -d <APP_HOST1> -m mac --mac-source <DEVICE_MAC> --dport 443 -j DNAT --to-destination 10.0.0.1:9040
$ sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp -d <APP_HOST2> -m mac --mac-source <DEVICE_MAC> --dport 443 -j DNAT --to-destination 10.0.0.1:9040
$ sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp -d <APP_HOST3> -m mac --mac-source <DEVICE_MAC> --dport 443 -j DNAT --to-destination 10.0.0.1:9040
Таким образом мы разрешили попадание в Tor только трафика с трех хостов определенного устройства, весь остальной трафик не покинет
интерфейса wlan0, а следовательно, ничего скрытого передано не будет.
Останется лишь убедиться, что в работе приложения не появилось дефектов.
Блокировка определенных хостов
В данном случае неплохим решением было бы выдавать сообщение о том, что хост заблокирован в нашей сети. Для этого можно поднять веб-сервер и переадресовывать клиентов с заблокированного ресурса на страницу с сообщением. Для блокировки ресурсов по HTTPS понадобится как минимум сгенерировать самоподписанный сертификат и настроить веб-сервер на работу по протоколу HTTPS. Блокировку можно произвести прямо в таблице NAT:
$ sudo iptables -t nat -I PREROUTING 1 -i wlan0 -p tcp -d m.vk.com --dport 80 -j DNAT --to-destination 192.168.1.82:80
$ sudo iptables -t nat -I PREROUTING 1 -i wlan0 -p tcp -d m.vk.com --dport 443 -j DNAT --to-destination 192.168.1.82:443
Заблокированный в рамках сети AP хост
Блокировка рекламных сетей с целью повышения анонимности
Уже давно известно, что скрипты рекламных сетей стараются скрытно собрать максимум возможной информации о посетителях сайтов, представляя таким образом дополнительную угрозу анонимности. К счастью, на собственной AP мы можем по умолчанию заблокировать для клиентов связь рекламных скриптов с рекламными сетями. Для этого предлагаю вернуться к утилите dnsmasq: в качестве одной из опций своего конфига утилита предлагает дополнительный источник DNS-информации (наравне с /etc/hosts). Изменим файл с конфигом Dnsmasq (./dnsmasq.conf):
## Дополнительный источник DNS-информации, содержащий рекламные сети
addn-hosts=/full/path/to/my_dns_hosts.txt
Содержимое файла имеет точно такой же формат, как и /etc/hosts, поэтому с его наполнением проблем быть не должно. Источник блокируемых ресурсов можно выбрать самостоятельно из
Заключение
Вот таким незамысловатым способом мы создали точку доступа, весь трафик которой «прячется» за Tor’ом, а в качестве приятного бонуса мы получили возможность «жонглировать» всем проходящим через нее трафиком в собственных целях — как добрых, так и не очень.
Да, знаю многие заморачиваются (да, я и сам раньше) защитой своей точки, что-бы никто неподключился.
Но мне стало интересно, сколько подключится ко мне. Да все желающие могут бесплатно подцепиться.
Но потом мне стало интересно, а на сколько безопасно это в РФ ? Ведь чисто теоретически, если кто-то подключится и начнёт, каким-то криминалом заниматься, по хорошему могут потом ко мне прийти.
По началу, думал весь трафик загнать через прокси, но сегодня даже случайно попалась статейка на Хакере (Пока-что непробовал), загнать весь трафик в ТОР.
Код:
https://xakep.ru/2018/06/28/wi-fi-tor-proxy/В этой статье рассмотрим, как конфигурировать точку доступа Wi-Fi с автоматической анонимизацией всего исходящего трафика через сеть Tor, а также взглянем на некоторые полезные примеры ее применения как для простого пользователя, так и для исследователя безопасности.
Зачем нам Tor AP?
В последнее время на фоне массовых блокировок IP-адресов все меньше людей продолжает сомневаться, нужны ли механизмы проксирования и анонимизации в их повседневной жизни. Бесплатных VPN-клиентов появляется все больше, но, как
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
, далеко не всем из них безопасно полностью доверять: то качество реализации хромает, то
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
.Как известно, Tor «из коробки» предоставляет как механизм проксирования (читай: обхода блокировок), так и продвинутый механизм анонимности. Вся связь между узлами в сети Tor шифруется, а соединение с целевым узлом устанавливается посредством как минимум трех случайно выбранных узлов. Взяв за основу Tor и автоматизировав все процессы, происходящие при подключении к точке доступа (далее — AP), в результате мы получим весьма интересный инструмент, польза от которого отнюдь не исчерпывается обходом блокировок.
Первичная настройка AP
Для создания точки нам понадобится какое-нибудь устройство, на котором можно запустить операционку (виртуалка тоже вполне сгодится). В качестве операционной системы, управляющей точкой, подойдет любой Linux-дистрибутив. Конкретно я буду использовать Debian-based. Для превращения всего этого в AP понадобится Wi-Fi-адаптер.
Если все это выполнено, можно приступать к первичной настройке. Итак, в первую очередь подключаем Wi-Fi-адаптер. Вывод ip addr show wlan0 (wlan0 — имя интерфейса адаптера, может быть другим) должен быть такой, как на скрине.
Детали сетевого интерфейса адаптера
На данный момент сетевой интерфейс не сконфигурирован. Первым делом активируем Wi-Fi, освободив его от влияния вездесущего Network Manager’а:
$ sudo nmcli radio wifi off
$ sudo rfkill unblock wlan
Теперь выберем и назначим интерфейсу адаптера IP-адрес, все адреса из
маски которого будут назначаться в дальнейшем клиентским устройствам:
# ip addr add 10.0.0.1/24 dev wlan0
Третьим пунктом мы переведем адаптер в режим AP: делать это мы будем одним из наиболее распространенных способов — с помощью утилиты
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
, позволяющей сконфигурировать программную точку доступа. Hostapd присутствует в большинстве штатных репозиториев.$ sudo apt-get install hostapd
Далее нужно создать конфиг для hostapd (./hostapd.conf):
## Имя интерфейса адаптера
interface=wlan0
## SSID AP
ssid=TorNet
## Автоматический выбор канала
channel=1
## Разрешить подключение со всех MAC-адресов, которые не запрещены
macaddr_acl=0
## Файл с запрещенными для подключения MAC-адресами
deny_mac_file=./denied_macs
## Логировать все модули (IEEE, WPA, IAPP и так далее)
logger_syslog=-1
## Логировать с модулей только informational messages
logger_syslog_level=2
## Режим: IEEE 802.11g
hw_mode=g
## Включить аутентификацию WPA/2
wpa=2
## Пароль WPA для доступа к точке
wpa_passphrase=xxxxxxxx
## Принимаемые алгоритмы управления ключами
wpa_key_mgmt=WPA-PSK WPA-EAP WPA-PSK-SHA256 WPA-EAP-SHA256
После этого уже можно будет запустить hostapd для перевода Wi-Fi-адаптера в режим AP с описанной конфигурацией:
# hostapd ./hostapd.conf
Hostapd и Network Manager
В некоторых версиях hostapd присутствует баг, связанный с блокировкой интерфейса Network Manager’ом и не позволяющий запускать AP. В
результате запуска hostapd возникает следующая ошибка:
Interface wlan0 wasn't started
Подробно баг и возможный воркэраунд описан
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
.Однако по понятным причинам подключиться к точке привычным образом пока будет невозможно.
Попытка подключения к AP без DHCP
Для устранения этих причин понадобится другая утилита — dnsmasq, которая позволит развернуть службы DHCP и DNS. DHCP сейчас представляет больший интерес.
Ставим dnsmasq из стандартного репозитория:
$ sudo apt-get install dnsmasq
Dnsmasq также нуждается в предварительной настройке (./dnsmasq.conf):
## Интерфейс для прослушки DHCP-запросов
interface=wlan0
## Диапазон выдаваемых клиентам адресов и срок действия
## (должны подходить под маску сетевого шлюза адаптера!)
dhcp-range=10.0.0.10,10.0.0.250,8h
## Шлюз по умолчанию
dhcp-option=3,10.0.0.1
## DNS-шлюз
dhcp-option=6,10.0.0.1
## Логировать DNS-запросы
log-queries
## Логировать DHCP-запросы
log-dhcp
Запускаем DHCP-сервер в составе dnsmasq:
# dnsmasq -C ./dnsmasq.conf
Теперь подключение к AP становится возможным с любых устройств. Чтобы наша точка наконец заработала в обычном режиме, осталось ответить на главный вопрос: откуда точка будет брать доступ в интернет. Для получения ответа предлагаю взглянуть на схему ниже. Большинство читателей, так или иначе соприкасавшихся с настройкой сетей, заметят на нем достаточно привычную схему связывания сетей. Именно этот способ мы и будем использовать.
Схема доступа в интернет с AP
Как видно из рисунка, для доступа в интернет понадобится еще один сетевой интерфейс. Это может быть как Ethernet-подключение (eth0), так и второй Wi-Fi-модуль (wlan1).
Например, при создании AP из виртуальной машины такой интерфейс создается автоматически (eth0). Сейчас у нас готово все, за исключением связи между интерфейсами (обозначенной красной линией).
Эта связь представляет собой пересылку пакетов с одного интерфейса на другой. Для тестирования работоспособности нашей AP пока
сгодится и обычный механизм NAT:
$ sudo sysctl -w net.ipv4.ip_forward=1
$ sudo iptables -P FORWARD ACCEPT
$ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
На данном этапе AP заработала в обычном режиме: принимает клиентов и предоставляет им доступ в интернет с IP-адреса, выданного нам нашим
провайдером. Это, конечно же, замечательно, но для наших целей недостаточно. Поэтому теперь настало время перенаправления всего
клиентского трафика в Tor.
Вторичная настройка AP
Перед перенаправлением всего трафика AP в Tor необходимо установить сам Tor:
$ sudo apt-get install tor
И настроить его как Transparent Proxy с помощью конфигурационного файла (расположенного здесь: /etc/tor/torrc):
## Включаем доступ к onion-ресурсам
VirtualAddrNetwork 192.168.100.0/10
AutomapHostsOnResolve 1
## Порт для прозрачного проксирования в рамках нашей сети
TransPort 10.0.0.1:9040
## Порт для анонимного резолвинга имен хостов
DNSPort 10.0.0.1:53
Этих настроек для наших нужд вполне достаточно, поэтому можем запускать Tor как сервис:
$ sudo service tor start
На текущий момент вывод netstat -tunapl должен быть примерно таким, как на скрине ниже. Мы видим все запущенные нами сервисы на текущий момент.
Открытые порты на AP
Если сейчас подключиться к AP, то мы по-прежнему будем выходить в интернет с домашнего IP, поэтому осталось всего-навсего включить проксирование через Tor с помощью iptables:
# Перенаправление всего TCP-трафика
$ sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp -j DNAT --to-destination 10.0.0.1:9040
# ...и DNS-трафика в отдельности
$ sudo iptables -t nat -A PREROUTING -i wlan0 -p udp --dport 53 -j DNAT --to-destination 10.0.0.1:53
Также нужно удалить предыдущее правило, включающее маскарад между сетевыми интерфейсами (NAT):
$ sudo iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
Двумя новыми правилами мы добились следующего: подмены пункта назначения всего TCP-трафика в момент появления пакетов на сетевом интерфейсе Wi-Fi-адаптера и редиректа DNS-запросов (протокол UDP).
Подмененный пункт назначения — запущенный сервис Tor с Transparent Proxy. Стоит обратить внимание, что на этих двух правилах настройка iptables завершается. Теперь можно убедиться в работоспособности настроенной Tor AP, посетив с любого подключенного к ней устройства 2ip.ru.
PoC
RPi как AP
«Малинка» отлично подходит в качестве управляющего устройства AP: всего несколько дополнительных действий с автоматической разверткой конфигурации при старте системы (systemd, initV), и останется всего лишь воткнуть USB-кабель в «розетку» для включения точки в любой нужный момент.
Практическое применение AP
Имея собственную AP, с которой соединяются клиентские устройства, мы по умолчанию получаем возможность наблюдения за всем трафиком своей сети, как пассивного, так и активного. Перенаправление в Tor — это лишь один из вариантов применения AP в прикладных задачах.
Анализ трафика клиентских устройств
Пожалуй, самый очевидный вариант, который сразу же приходит в голову.
Никто не запрещает запустить на AP Wireshark или tcpdump и захватывать трафик конкретного клиента либо всех клиентских устройств сразу до момента перенаправления трафика в Tor.
Возможности для захвата здесь ограничены лишь уровнем защищенности конечного устройства, пользователя и приложения. Тема достаточно известная, поэтому подробно на ней останавливаться не будем.
Анализ сетевой активности приложений
В ИБ часто возникает задача проанализировать сетевую активность определенного приложения. Например, у нас имеется мобильное приложение, которое при работе использует несколько известных нам хостов. Мы хотим методом черного ящика проверить, не ведет ли приложение какие-либо скрытые передачи на дополнительные удаленные хосты.
Причем на самом устройстве мы это сделать не можем — нет соответствующих прав на уровне ОС. Зато у нас есть AP, находящаяся полностью под контролем и с максимальными правами! Ее использование будет практически аналогично анализу трафика на целевом устройстве.
Попробуем исследовать работоспособность приложения без скрытого доступа к каким-либо дополнительным ресурсам. Заранее мы отключили все остальные источники побочного трафика, генерируемого из других приложений. Скрытые передачи в данном случае не обязательно должны быть вредоносными — это могут быть механизмы антиспама (контроль того, что API приложения действительно используется с мобильного устройства), рекламы и так далее. Мы можем пропускать трафик методом белого ящика — запрещено все, что не разрешено:
$ sudo iptables -t nat -F
$ sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp -d <APP_HOST1> -m mac --mac-source <DEVICE_MAC> --dport 443 -j DNAT --to-destination 10.0.0.1:9040
$ sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp -d <APP_HOST2> -m mac --mac-source <DEVICE_MAC> --dport 443 -j DNAT --to-destination 10.0.0.1:9040
$ sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp -d <APP_HOST3> -m mac --mac-source <DEVICE_MAC> --dport 443 -j DNAT --to-destination 10.0.0.1:9040
Таким образом мы разрешили попадание в Tor только трафика с трех хостов определенного устройства, весь остальной трафик не покинет
интерфейса wlan0, а следовательно, ничего скрытого передано не будет.
Останется лишь убедиться, что в работе приложения не появилось дефектов.
Блокировка определенных хостов
В данном случае неплохим решением было бы выдавать сообщение о том, что хост заблокирован в нашей сети. Для этого можно поднять веб-сервер и переадресовывать клиентов с заблокированного ресурса на страницу с сообщением. Для блокировки ресурсов по HTTPS понадобится как минимум сгенерировать самоподписанный сертификат и настроить веб-сервер на работу по протоколу HTTPS. Блокировку можно произвести прямо в таблице NAT:
$ sudo iptables -t nat -I PREROUTING 1 -i wlan0 -p tcp -d m.vk.com --dport 80 -j DNAT --to-destination 192.168.1.82:80
$ sudo iptables -t nat -I PREROUTING 1 -i wlan0 -p tcp -d m.vk.com --dport 443 -j DNAT --to-destination 192.168.1.82:443
Заблокированный в рамках сети AP хост
Блокировка рекламных сетей с целью повышения анонимности
Уже давно известно, что скрипты рекламных сетей стараются скрытно собрать максимум возможной информации о посетителях сайтов, представляя таким образом дополнительную угрозу анонимности. К счастью, на собственной AP мы можем по умолчанию заблокировать для клиентов связь рекламных скриптов с рекламными сетями. Для этого предлагаю вернуться к утилите dnsmasq: в качестве одной из опций своего конфига утилита предлагает дополнительный источник DNS-информации (наравне с /etc/hosts). Изменим файл с конфигом Dnsmasq (./dnsmasq.conf):
## Дополнительный источник DNS-информации, содержащий рекламные сети
addn-hosts=/full/path/to/my_dns_hosts.txt
Содержимое файла имеет точно такой же формат, как и /etc/hosts, поэтому с его наполнением проблем быть не должно. Источник блокируемых ресурсов можно выбрать самостоятельно из
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
— там можно найти hosts-файлы под блокировки различных масштабов (в самой большой сборке было около 71 тысячи различных хостов).Заключение
Вот таким незамысловатым способом мы создали точку доступа, весь трафик которой «прячется» за Tor’ом, а в качестве приятного бонуса мы получили возможность «жонглировать» всем проходящим через нее трафиком в собственных целях — как добрых, так и не очень.
