id: Гость   вход   регистрация
текущее время 14:08 28/03/2024
Автор темы: Гость, тема открыта 18/12/2013 15:44 Печать
Категории: софт, анонимность, tor
создать
просмотр
ссылки

tor без TBB


как можно использовать tor без tor browser? например, с обычным Firefox 26 (знаю, что это менее безопасно) или lynx? вроде, нужно прокси использовать?
ОС: ubuntu 13.10


пожалуйста, опишите поподробнее.


 
На страницу: 1, 2 След.
Комментарии
— Гость (19/12/2013 20:05)   <#>

«То обсуждение» возникло из-за моей в нём ссылки на «ту другую тему». Все в курсе этих тем и обсуждений. Если кто-то высказался по теме ранее ещё в первом топике, то с чего бы отменять сказанное при повторном обсуждении той же темы?


Я читаю всё, но если вы не подписываетесь, то не жалуйтесь потом, что вас, де, не так поняли. Хотите выступать от коллективного анонимного бессознательного — ваше право, но потом не нойте.


А я думал, что молчание — знак согласия. В любом случае, ответ давался на конкретные реплики, а не конкретным лицам. Вы ли писали эти реплики, или кто-то другой — не важно, я привёл ответ именно на них.


ваши загадки производят впечатление лишь на полных профанов


ОС: ubuntu 13.10

Это вопрос топикстартера, если что, который должен намекнуть советчикам на квалификацию спрашивающего, поэтому я написал явно:

как обойти вами описанные правила iptables, если их накатили поверх свежеустановленной Ubuntu'ы

Вы же ведь ему отвечали изначально, так?


Если теорема неверна в одной из ситуаций, то она неверна вообще.


Ну, у вас тогда не демагогия, а вообще толстый троллинг:

Даёте ссылку на тему где вы же слили обсуждение "проблем" с sudo. Критикуйте конкретно, иначе ваши загадки производят впечатление лишь на полных профанов.

И это при том, что по ссылке как раз всё было объяснено, я всем всё ответил, и на мой последний пост ни одного возражения не последовало, и вы это назвали сливом? Развёрнутые объяснения по сути для вас, получаются, как об стенку горох, отсылку к мнению других участников pgpru, которые тоже читали все эти ветки — демагогия. Как ещё с вами разговаривать?

Знаю минимум 2 рабочих универсальных метода обхода файерволла, настройка которого ограничилась этими правилами. Предлагаю вам догадать об этом самому.
Уже три. Третий не настолько универсален, но на очень многих конфигурациях сработает.

Ладно, учиться вы, я уже понял, не намерены, поэтому сливаю вас в назидание остальным:

  1. Обход через ping. Surprize? Лечится либо удалением ping (а также, наверно, других утилит, которые работают через ICMP, типа traceroute?) из системы вообще, либо полным закрытием ICMP в iptables для всех. ICMP-пакеты реально посылаются от рута, какой бы юзер их ни посылал, поэтому с точки зрения iptables владельцем ICMP-пакетов всегда является root. Закрывая их для root'а (проще просто для всех закрыть), мы закроем их для всех.
  2. Обход через IPv6. Простые методы лечения почему-то не помогают, поэтому рекомендуется делать через правку конфигов GRUB. iptablesip6tables, iptables не фильтрует IPv6, и по умолчанию IPv6 разрешён для всех и полностью. Surprize?
  3. Обход через общение с локальными демонами. У кулхацкеров принято на lo не фильтровать. Если у вас запущен какой-нибудь демон, то анонимный юзер может с ним общатся (пример — демон печати, но могут быть и другие примеры). Анонимный юзер ему передаёт по лупбэку информацию, всё ОК, но демон может отправить информацию в сеть напрямую. Это может быть локальный принтер или, что хуже, какой-то удалённый принтер по сети. Казалось бы, файлы из анонимного профиля не могут просто так утечь в сеть, а на самом деле запросто. Мораль: фильтровать на lo надо, если нет полного доверия к локальным демонам. Кстати, раз топикстартер ведёт речь об Ubuntu, то там локальных демонов, запущенных по умолчанию, хоть жопой жуй (тот же avahi).
  4. Обход через доступ к портам Tor'а других пользователей. Защита — фильтрация всего на lo.
Как итог, учёт этих пунктов (1-4) порождает уже не такой простой конфиг для iptables в сколь-нибудь реалистичных десктопных конфигурациях, да ещё и дополнительные настройки придётся внести (в тот же GRUB, например).


Tails на системе с реальным IP не защищает от утечки этого IP. Ещё информация о железе утекает: зашёл на подставной сайт, а там универсальный эксплоит от АНБ для firefox, они пошарились по системе и утянули инфу о железе. Потом вы загрузили другую систему, незащищённую и неанонимную, на том же железе, пошли youtube какой-нибудь через Adobe Flash смотреть, а youtube — тоже гугл и АНБ. Никто не запрещает проприетарному закрытому бинарю порыскать ваш уникальный отпечаток в виде информации о железе и слить его к себе на сервера. А потом вдруг ВНЕЗАПНО выясняется, что у кого-то анонима в Tails было идентичное железо, с точно такими же идентификаторами (а идентификаторы железа уникальны). Продолжение драмы с участием хлебовозок, пативенов (или что там сейчас модно?) можете дописать сами.

P.S. А с убунтой всё плохо, и, возможно, даже ещё хуже.
— Гость (22/12/2013 19:23)   <#>
Поскольку появился конструктив, отвечу на ваше сообщение. Первая его половина – флуд, перейду сразу к содержательной части. Что нужно начинающему пользователю без квалификации? Завести Тор и устранить утечки из-за ошибок конфигурации (если он не шпион в тылу у врага, когда каждая ошибка как у сапёра). Все перечисленные вами утечки – это целенаправленные атаки на раскрытие анонимности, т.е. угрозы совершенно другого уровня. Если нет злонамеренных атак, то веб-браузер не пошлёт пинг и не свяжется по ipv6. Для получения информации от локальных процессов нужен как минимум сообщник в локальной сети. Доступ к Тор других пользователей ... а какие ещё могут быть пользователи у начинающего кроме веб-браузера? Ему даже один браузер сложно в Тор направить, не говоря уже о других программах, которые без специальной настройки в Тор не пойдут.

Тем не менее, спасибо за список, хотя перечисленные способы известны, но это ещё одна возможность освежить их в памяти и уделить внимание тому, чему не придавалось особого значения.

1. С пингом понятно, в написанных мной правилах умышленно оставлен icmp, т.к. этот протокол содержит полезные сообщения необходимые для устойчивой работы сетевого оборудования (например source-quench). Для работы через Тор оставлять icmp – это ошибка, согласен. Только непонятно зачем удалять полезные утилиты из системы (ping, traceroute и т.п.), когда они легко блокируются сетевым экраном.

2. С отключением ipv6 тоже вроде проблем никаких – применяется опция ядра ipv6.disable=1 в загрузчике. В приведённой вами ссылке проблема была не с ipv6, а с настройкой grub2. Пользователю Тор этот загрузчик не нужен, который разработан по-видимому для корпоративных нужд.

3. Зачем фильтровать lo, если можно оключить ненужные службы? Получается двойная цена – они проедают ресурсы машины и ещё требуют к себе внимания для блокировки, усложняя сопровождение системы. К тому же порты – не единственный способ общения процессов – есть ещё unix-сокеты, fifo, новая шина dbus. Куда разумней фильтровать внешний интерфейс локальной сети – любой такой процесс может послать данные наружу только через него.

4. Фильтровать lo для разграничения пользователей по портам Тор? Если правильно понял, предлагается для каждого локального приложения создать пользователя и доступ к разрешённому ему порту установить фаирволом. Когда пользователей несколько, получается довольно затратный способ в плане сопровождения, лучше использовать авторизацию на socks-портах. Если Тор-клиент установлен на шлюзе для внутренней сети, тогда распределение пользователей (IP-адресов) по портам Тора наверное предпочтительной авторизации. Но о шлюзе здесь речи нет, а на локальной машине разных программ-пользователей Тора кроме веб-браузера тоже быть не должно – на этом сайте рекомендуется пользоваться через Тор только одним единственным специально разработанным http-клиентом Видалия во избежание профилирования. Поэтому правильней наверное говорить об ограничении доступа к Тору всем кроме Видалии.

В итоге, с учётом перечисленных вами угроз, получается не такая уж сложная конфигурация. Предлагаю найти брешь следующей системе (с сохранием возможности выхода в Интернет). Используется стандарное подключение к провайдеру: получение IP-адреса по dhcp и подключение к pptp-серверу. Интерфейс локальной сети eth0, на выходе в Интернет – ppp0. Для ограничения локальных процессов фильтруется не lo, а eth0 – в локальной сети разрешено только подключение к pptp-порту (1723/tcp) и протокол GRE. Лучше конечно явно указать адрес pptp-сервера, но он может меняться, т.к. получается по dhcp. Можно модифицировать dhclient-script (или обрабатывать файл аренды) и получать адреса pptp-сервера и шлюза локальной сети из переменных окружения скрипта. Плюсом этого является ещё возможность фильтрации по mac-адресу шлюза.

1. Правила сетевого экрана



2. grub.conf



Для подключения к провайдеру нужно временно разрешить доступ к локальному dns-серверу (53/udp), который нужен для разрешения имени pptp-сервера в IP-адрес. Ещё один плюс модификации dhclient-script – получение IP-адреса dns-сервера, что позволяет фильтровать UDP на этапе подключения к Интернету по IP, а не только по порту. После подключения протокол UDP целиком блокируется вышеприведёнными правилами. Для простоты можно ничего из этого не делать, но загрузить эти правила непосредственно перед выходом в Тор.

Существуют ещё "сырые" сокеты (типа dhcp), не подпадающие под правила iptables, но подчинающиеся ebtables. Об их фильтрации мне пока неизвестно, может кто-нибудь напишет об этом.

Написанное про идентификацию железа неспецифично для Tail и верно для любого софта кроме виртуалок. Поэтому конкретно Tails ничем не виноват больше остальных. Понятно, что максимальная безопасность возможна лишь при физической изоляции пользователя (отдельная машина) от Тор-клиента (отдельный роутер), но сейчас речь идёт о типичной ситуации.
— Гость (23/12/2013 01:54)   <#>

Первая его половина — ответ на ваши ложные обвинения в том, чего и близко не было.


Странное видение проблемы. Получается, что пользователь настолько глуп, что не может аккуратно настроить браузер по инструкции, зато может легко орудовать с правилами iptables? Очень «реалистично» звучит. Но даже если и так, он вашим методом какие-то утечки если и закроет, то не обнаружит, что утекает, а это очень плохо. Чтобы обнаружить утечки вашим методом, там надо помимо DROP ещё делать логирование пакетов, а потом уметь их читать, что ещё одно усложнение.

Если цель — проверить конфигурацию, то чем плох снифер, который запускается одной командой и сразу показывает всё, что летит мимо Tor'а? Зачем использовать iptables для того, для чего он толком не предназначен, когда есть банальное

Список guard'ов берётся из netstat -apn, НУЖНЫЙ_IP_С_ИЗВЕСТНЫМ_ПРОИСХОЖДЕНИЕМ — то, что вам совсем влом отключать на время тестов.

Скажем так, если бы вы в /comment74754 сразу сказали, что это не запрет трафика в обход Tor, а лишь частичное закрытие некоторых утечек, что не запрещает кучу других и, в конечном счёте, реально не страхует от уязвимостей, то всех этих вопросов и дискусии не возникло бы. А советовать непонимающим новичкам как панацею нечто простое, не предупредив о последствиях — медвежья услуга.


Герои этой атаки тоже думали, что они не в тылу врага, они — обычные новички-обыватели, их миллионы, и целенаправленные атаки на раскрытие анонимности им не страшны. История ничему не учит?


Что вы имеете в виду?


Пусть пользователь создал отдельного юзера для Tor и отдельного юзера для пользования Tor'ом. Теперь он думает, что из-под юзера, пользующегося Tor'ом (от которого запущен TBB и всё остальное анонимное) ничего мимо Tor'а не уйдёт, т.к. файерволл же, поэтому он параллельно логинится в других иксах под другим юзером и запускает флэши и скайпы. Помимо того, что они сами зловреды, у пользователя могут ещё и быть заражёнными разными троянами пользовательские профили, от которых он эти флэши и скайпы запускает. Зловред обращается через локальный порт Tor'а и смотрит, с какого эксита пришёл пакет на ему подконтрольный узел в каком-нибудь Verizon. Всё, информация о том, через чей эксит сейчас работает анонимный юзер на ПК, утекла атакющему. Я выше привёл конкретную ссылку, где описан такой тип атаки.


Вопрос «зачем?» неправильный. Я просто формально перечислил все способы, которые решают поставленную задачу. Конечно, лучше просто заблокировать, но если вдруг пользователь настолько глуп, что ему сложно ковыряться в iptables, вылечить перхоть можно, отрубив голову (тупо удалить файлы всё же проще).


В приведённой ссылке проблема в том, что отключение IPv6 через переменную в sysctl почему-то не работает, хотя должно, и замечено это было чисто случайно. Получились очень опасные грабли.


Так они же нужны — это раз. Tor запущен почти всегда ⇒ службы почти всегда будут отключены что ли? Это два. Каждый раз перед включением Tor их отключать неудобно, и рано или поздно начинаешь забывать это сделать — три. Например, запущенный ntp нужен для защиты от фингепринтинга по времени:

One type of attack, for example, would identify users by minute differences in the clock times on their computers. © АНБ

musicpd нужен, чтобы во время работы в Tor слушать музыку, и т.д. И я не хочу давать права тому пользователю, который пользуется Tor'ом, на какое-либо взаимодействие с этими локальными демонами.

Кстати, с принтером пример ненадуманный. Вот установили вы настройки печати на принтер с реальным IP, который находился в вашей локалке, а потом уехали с ноутбуком в другое место, забыв поменять настройки. И всё, при печати файл отправляется через интернет на всё тот же принтер. У нас так один деятель умотал в MIT, а настройки принтеров как следует подчистить забыл. Народ потом рассказывал, как забирал с локального принтера документы, которые он по ошибке на нём печатал, сам при этом находясь в другой стране.


Да, поэтому, если по-хорошему, то нужны виртуалки.


Во-первых, он может послать данные не сразу. Я не хочу обсуждать, зачем может понадобиться печать во время работы с Tor'ом (пусть пример немного надуманный), но это очень показательный пример: допустим, вы ставите по ошибке (или злонамеренная малварь ставит) файл на печать. Локальный демон заблокирован во внешку, к примеру, полностью, и напечатать он не может. Однако, в пуле очередь на печать стоит, и время от времени демон пытается связаться с принтером. Вполне возможно, что через несколько дней, когда вы уже обо всём забудете, отключите Tor и поменяете правила iptables, этот демон печати таки достучится до принтера и сольёт на него файл.

Во-вторых, фильтровать демона по тому, кто его и о чём попросил, не получится. Когда демон получил от кого-то легитимный запрос, он полезет в сеть от своего имени и со своими правами. Если эти права у него есть, он ни в чём не ограничен.


Да.


Во-первых, одно органично дополняет другое. Во-вторых, никто не говорил, что анонимность — лёгкая в сопровождении штука. Прикладные программы и браузер очень дырявы:

• Current: Torbutton and TBB prevent CNE success.
Possible success against "vanilla" Tor/Vidalia.

Не найду точную цитату, но АНБ привыкло жить на уровне «под любой firefox/TorBrowser у нас есть готовый эксплоит», причём было замечание «под недавно релизнутый TBB у нас ещё нет готового эксплоита, но мы полагаем, что найти уязвимость и сделать его — это вопрос ближайшего времени». Поэтому, в-третьих, авторизация на SOCKS-портах куда менее безопасна, чем настройка файерволла: если два разных юзера, зацепленные на разные SOCKS-порты, вдруг окажутся скомпрометированными атакующим, он сможет трафик одного из них посылать через SOCKS-порт другого и полностью связать этих юзеров в один профиль. А если используется фильтрация файерволлом, то её не обойти никак без уязвимости уровня local root.


Одно может дополнять другое. Вдруг одна машина в локалке полностью компрометируется и зловред поменяет её IP-адрес?


Не должно, если этого можно избежать. Как запускать через браузер, например, ssh? А джаббер, если все его веб-клиенты не поддерживают PGP/OTR-шифрование?


Видалия — рюшечка для хомяков. В последней версии TBB от неё вообще отказались. Опытным пользователям видалию не рекомендовали вроде никогда. В крайнем случае через Control Port с помощью консольной команды можно получить всё то же, что рисует видалия, и даже больше, см. «Об управлении процессом Tor из командной строки с помощью Control Port». Конечно, если так сильно хочется смотреть на карту мира, то не стоит изобретать велосипед, и можно воспользоваться видалией.


Помимо вышеозвученных уязвимостей в глаза бросаются следующее:
  1. Хоть я не большой знаток iptables, но всё же: не вижу у вас keep state в правилах. Вы независимо разрешаете трафик в обе стороны? Позволяете внешнему узлу инициировать соединение с вами? Иначе как понимать строку iptables -A INPUT -i $isp -p tcp -j ACCEPT?
  2. ISP догадывается, что вы ходите на pgpru.com, и знает его IP. Он выдаёт вам в качестве DHCP-ответа такой IP-адрес и выделяет вам такую подсеть, что вы с pgpru.com оказываетесь в одной локальной сети — какой-нибудь 217.16.21.x. Пусть, кроме того, ваш анонимный профиль скомпрометирован атакующим, и там сидит зловред, игнорирующий настройки браузера, а единственная помеху ему — ваши правила iptables. Поскольку роутинг устроен так, что пакеты в локальную подсеть идут напрямую, а не через gw, ваш ПК попытается обратиться на этот подставной сервис. Послать tcp-пакет у него, допустим, не получится, т.к. правила блокируют, но arp-запрос, который ему предшествует — запросто. Если arp-запрос на подставной IP от вас получен, значит, вы действительно пытались зайти на этот сайт. Что нужно: уязвимость в анонимном профиле (элементарно доставляется через FoxAcid) и злонамеренность ISP, подкрутившего настройки своего DHCP-сервера под ваш случай (дополнительный IP он может повесить на ту же свою сетевую, где и его gw-сервис для вас).


Жеесть...


При чём здесь сокеты? ebtables, судя по гуглу, фильтрует так же, как iptables, но протоколы более низкого уровня (IP). Например, им можно фильтровать пакеты по MAC-адресам (но вся фильтрация почему-то только на мостах). Есть ещё arptables.


Tails виноват в том, что он не страхует тот случай, когда провайдер вам выдаёт реальный IP-адрес. В этом случае незачем обходить файерволл, т.к. этот адрес утягивается из ifconfig или из любой сторонней программы, которая сделает нужный syscall к ядру (при желании её можно написать самостоятельно или утянуть готовую из интернета). Вроде бы в Tails пытались что-то придумать на этот случай.

Про защиту от идентификации железа сказано верно, но, кажется, на этот счёт у них тоже были какие-то планы. Чисто технически никто не запрещает сделать так, чтобы с LiveCD запускалась виртуалка.

P.S. Когда-то очень давно я создавал себе правила с затягиванием гаек. Я тогда не всё понимал, но общие идеи были схвачены. В примере USERNAME — тот, кто пользуется Tor'ом, privoxy запущено от имени юзера privoxy, а tor запущен от имени пользователя tor. Ничего кроме трафика tor в сеть не было разрешено. Выглядело (вывод iptables-save) это примерно так:

Тут надо ещё ICMP заблочить, как минимум. Это не готовый пример, а просто намёк на то, как закручиваются гайки в файерволлах. В частности, у любого правила должны быть указаны src IP, dst IP и dst port (если возможно), интерфейс и uid-owner (обязательно). Разные правила, отличающиеся хоть одной опцией, не надо сливать в одно, поэтому INPUT и OUTPUT для одного и того же потока прописываются раздельно. Из-за перечисленного коротко не получается, даже самое простое тянет на кучу длинных правил.
— Гость (23/12/2013 02:02)   <#>

Тут лучше добавить что-то типа ! -d MY_LOCAL_NETWORK, что лучше, чем destination=any.
— Гость (23/12/2013 07:19)   <#>

Пример искуственный, потому что предполагает, что малварь получит IP-адрес через Tor (сделает DNS-резолвинг через Tor SOCKS), а потом стукнется напрямую. Но можно представить более логичную атаку: всех посетителей конкретного сайта кормим браузерным эксплоитом, который потом будет непрерывно стучаться на конкретный IP. Далее кооперируемся с провайдерами и просим временно выставить для DHCP-клиентов, пользующихся Tor'ом, какой-нибудь IP из той же подсети. Далее ловим, от кого придёт ARP-запрос.

Для динамических адресов так можно за одну попытку быстро выследить всех, кто ходит на конкретный сайт. Для статических адресов атака усложняется, но работать будет, выглядит так: зная, какой статический IP-адрес у конкретного клиента провайдера, проверяем, ходит ли он на целевой сайт, выдавая на нём всем такой эксплоит, который будет стучаться на IP из той же подсети, что и статический IP-адрес клиента. Потом слушаем ARP-запрос на него, и всё работает так же. Правда, придётся заражать всех, чтобы выловить только одного.

Есть у меня сомнения насчёт того, что ARP-запрос отправится даже при зарезанном пакете, но, по-моему, это так. Надо будет поэкспериментировать. Без ARP-запросов атака работать не будет, но тот факт, что они не фильтруются iptables'ом — всем известная истина. В частности, ARP-запросы позволяют легко выяснить, жив ли или мёртв конкретный хост в локалке независимо того, включён ли на нём файерволл, т.е. по ARP он ответит всегда (ARP очень редко когда фильтруются).

Получается модификация АНБ-атаки с FoxAcid/XKeyScore на случай клиентов, которые забаррикадировались firewall'ом. В виртуалках при правильной организации внутренней виртуальной сети эти атаки, конечно, не сработают, т.к. трафик локалки ISP изолирован файерволлом и роутингом от локалки виртуалок.
— Гость (23/12/2013 19:37)   <#>

Извиняюсь, это гон, только что проверил. Во всяком случае, в BSD и Linux это так, судя по тестам. Пункт 2 не взлетит ни в каком виде.
— Гость (24/12/2013 21:41)   <#>
Зловред обращается через локальный порт Tor'а и смотрит, с какого эксита пришёл пакет на ему подконтрольный узел в каком-нибудь Verizon

Разве флеши и скайпы не надо настраивать на подключение через Тор?

Так они же нужны — это раз. musicpd нужен, чтобы во время работы в Tor слушать музыку, и т.д.

Что конкретно понимается под блокировкой? В моём понимании: есть принтер, для запрета доступа к нему пишется правило на время работы в Тор



У меня при просмотре фильмов трудностей нет, в установке ПО себя не ограничиваю, netstat -ltopn выдаёт список из трёх слушателей при отсутствии запущенных p2p:



Что по-вашему нужно заблокировать? Если ограничить доступ к почтовому серверу, станет неработоспособной локальная почтовая система. Хотя угроза с отложенной отсылкой сообщений существует при неправильной настройке (open relay), причём реальней чем в случае принтера. Тор и privoxy блокировать не надо, т.к. они предназначены для выхода в сеть. Есть ещё usb-принтер, когда нужно печатать – запускаю cups. Но зачем блокировать cups если принтер к сети не подключен?

Хоть я не большой знаток iptables, но всё же: не вижу у вас keep state в правилах. Вы независимо разрешаете трафик в обе стороны? Позволяете внешнему узлу инициировать соединение с вами? Иначе как понимать строку iptables -A INPUT -i $isp -p tcp -j ACCEPT?

После правил для lo следует



это блокирует все входящие соединения.



Похоже что не хватает правила с ESTABLISHED для цепочки OUTPUT, без него не работает. Потом, какой смысл указывать 127.0.0.1 в INPUT для локального интефейса? Кроме 127.0.0.0/8, других адресов у lo нет, поэтому опция -d лишняя. Опция -s тоже, т.к. транзитный пакет с другого интерфейса (не lo) не попадёт из-за FORWARD DROP. И по-моему в OUTPUT указывать -s вообще бессмысленно, т.к. пакет идёт от процесса и исходящий IP-адрес получает после попадания на выходной интерфейс. Для lo имеет смысл только -d 127.0.0.0/8 в OUTPUT. Я бы написал кусок правил, относящихся к lo, так:



ISP догадывается, что вы ходите на pgpru.com, и знает его IP. Он выдаёт вам в качестве DHCP-ответа такой IP-адрес и выделяет вам такую подсеть, что вы с pgpru.com оказываетесь в одной локальной сети — какой-нибудь 217.16.21.x.

Для такой атаки нужен доступ к порту 80/tcp через lan, а он запрещён правилами, поэтому arp-запроса не будет. Конечно, если атакующий знает эти правила, то он может заставить браузер постучаться на порт 1723/tcp, который разрешён для установления связи с pptp-сервером. Тогда спасает упомянутая фильтрация по IP- и mac-адресу шлюза. При наличии vpn эта атака тоже не проходит. Ещё вариант – отключать скрипты в браузере, т.к. по статистике утверждается что 90% экплойтов требует наличия скриптов.

Извиняюсь, это гон, только что проверил. Во всяком случае, в BSD и Linux это так, судя по тестам.

Это логично, т.к. для того чтобы был послан arp-запрос нужно чтобы пакет пришёл на сетевой интерфейс. Но iptables фильтрует между процессом и интерфейсом, и до интерфейса пакет не доходит. apr работает ниже – между IP и канальным уровнем.
https://www.frozentux.net/ipta...../tables_traverse.jpg
— Гость (25/12/2013 04:22)   <#>

Имелось в виду, что противник, знающий ваш Skype-аккаунт, запустит от имени Skype'а зловред, который полезет на порт Tor'а, чтобы узнать, какой у вас эксит под анонимным юзером. В качестве рабочей гипотезы можно считать, что skype — это сам по себе бэкдор, предоставляющий удалённый доступ к вашей машине противнику.


Блокирование пакетов правилами iptables.


Ещё раз: вы не желате закручивать гайки. Вы хотите запретить то, что опасно, а всё остальное оставить открытым. Я рекомендую делать иначе: запрещать вообще всё, а потом открыть то и только то, что необходимо. Пусть это будет неудобно и избыточно, но это страхует от непредвиденных неожиданностей. Мой метод подразумевает, что для каждой программы, работающей с lo, надо добавить свой набор правил iptables.


Ну и зачем вам локальная почта (порт 25)? Системные логи успешно ведутся и без неё.


Я бы сделал так:
  1. По умолчанию весь трафик на lo блокируем (DROP).
  2. privoxy запускаем от юзера privoxy.
    1. Разрешаем юзеру privoxy принимать пакеты на lo на 8118-ой порт.
    2. Разрешаем юзеру privoxy посылать пакеты на lo на 9050-ый порт.
  3. tor запускаем от юзера tor.
    1. Разрешаем юзеру tor принимать пакеты на lo на 9050-ый порт.
    2. Разрешаем юзеру tor посылать пакеты вовне с eth0 (или какой у вас там выходной интерфейс).
  4. Заводим юзера, который будет пользоваться Tor'ом. Пусть это будет tor_user. Разрешаем юзеру tor_user посылать пакеты на порты 8118 и 9050.
  5. Заводим юзера, от которого будет работать локальная почта. Разрешаем этому юзеру получать пакеты на 25-ый порт на lo (Отправлять пакеты ему нужно? Если да, то и отправлять).
  6. Добавляем в iptables правило, которое конкретным нужным юзерам разрешит отправлять пакеты на lo на 25-ый порт и принимать их оттуда. Нетрудно догадаться, что в список этих юзеров не надо включать, например, таких пользователей, как tor, privoxy и tor_user.
Ну и т.д. в том же духе (подразумевается, что все правила с keep state). Не держать запущенным CUPS, когда он не нужен — это тоже правильно.


Я блокирую не cups, а вообще всё, кроме того, что нужно. Например, если в вышеприведённом примере настройки в privoxy обнаружится эксплуатируемая дыра, она будет очень зажата в своих действиях: она может только принимать чужие пакеты и передавать их Tor'у, ни на один другой порт она ничего послать не сможет, даже если противник получит все права пользователя privoxy — это как пример.

Ну и, вообще, см. «Пример 1» из этой ссылки. Вы никогда не думали о такой возможности? Правда, iptables всё равно не умеет фильтровать входящие по юзерам, но в pf это делается запросто.


Всё может быть, я не проверял работоспособность. Это древние конфиги из загашника, там было много версий, и непонятно, какие из них рабочие.


Смысл всё в том же: всё, что не разрешено, запрещено. На lo могут легитимно появиться пакеты с другими адресами? Если нет, то незачем их разрешать, закрываем эту возможность. При какой-нибудь извращённой атаке, где противник пытается сменить IP-адреса на интерфейсах, это может даже помочь (пример искуственный, да).


В любом случае, каждое правило обабатывает пакет по совокупности всех его параметров, и у любого пакета всегда есть src IP и src port. Я знаю, каковы эти параметры у легитимного трафика, почему бы тогда их не зафиксировать в правилах? Это архитектурно правильное решение, оно подстилает солому на непредвиденные случаи.

В частности, если вы будете потом менять правила, добавлять (например) прозрачное проксирование, они станут сложными, вы где-то ошибётесь, забудете про какую-то важную деталь, и в итоге вполне может оказаться, что FORWARD появится, хотя вы этого не хотели.

Это спор о философии. Я придерживаюсь некоторых правил, чтобы минимизировать грабли в будущем. Кто-то другой может заявить, что «оно правильно работает и так», и ему не возразишь.

Есть непридуманный пример из реальной жизни. Если разрешаем всё, то зачем указывать конкретные протоколы? Оно же, казалось бы, эквивалентно:

Например, в pf когда-то была дыра, работающая, только если не был указан список конкретных протоколов. У меня он предусмотрительно был указан (tcp,udp,icmp), на всякий случай, потому система оказалась неуязвимой.

Запрещение всего, кроме того, что разрешено, делается из тех же соображений: чтобы защититься в т.ч. от непредвиденных ситуаций и багов, которые потенциально могут возникнуть в будущем. Защиту закручивание гаек не ослабляет, а оказаться полезным в будущем и подстелисть, где надо, соломку может. Почему бы тогда этим не воспользоваться?


При извратной настройке src IP может не совпадать с IP на интерфейсе, с которого отсылается пакет. Например, в pf во время экспериментов с policy based routing наблюдалось:

Интересно, что роутер может ретранслировать пакеты из одной сети в другую вообще буквально, т.е. не меняя у них ни MAC, ни src IP на свой собственный.

Т.е. пакет, полученный из одной локалки, передавался в другую локалку, подсоединённую к другой сетевой (и другому сетевому интерфейсу) буквально без изменений. Ещё можно сказать, что там был транзитный трафик, а тут собственный, но даже для собственного я не уверен, что программа не может переопределить src IP так, как ей захочется. На какой интерфейс попадёт исходящий пакет — определяется таблицей маршрутизации, а вот механизмы контроля назначения src IP мне до конца не понятны. Возможно, проспуфить IP может только root (но мы ведь рута тоже фильтруем в iptables...).

Ну, и, наконец, всегда есть оговорка «а вдруг атакующий поменяет IP на не тот через DHCP или ещё как-то?». Даже если это не страшно, то сам тот факт, что правило перестанет разрешать трафик, и пропадёт сеть, будет сигналом пользователю, что что-то поменялось.


Да, в ваших правилах из-за завязки на DNS-сервер IP не фиксирован:
iptables -A OUTPUT -o $lan -p tcp --dport 1723 -j ACCEPT
поэтому без фильтрации по IP сработает, но если IP указать в правилах, то без фильтрафии по MAC-адресам можно вроде обойтись.

Вообще, если глубоко копнуть, то всё это детский сад, и не поможет ничего. Атакующий в таком сценарии может заставить вас постоянно или с каким-то характерным паттерном делать любое из легитимных действий, и файерволл от этого не застрахует, это не его уровень, нужен DPI. К примеру, у вас клиент по pptp стучится раз в некоторое время, а атакующий заставит его стучаться туда в 10 раз чаще обычного. И это будет паттерн для ISP. По сути тут ничего нового, это обычная тайминг-атака. Или зловред мог бы начать скачивать через Tor длинные файлы с намеренными частыми прерываниями, формирующими некий конкретный отпечаток (типа начинаем качать, а потом на 12-ой секунде сбрасываем, и так повторяем бесконечное число раз). И для ISP этот отпечаток был бы как на ладони. Тут, правда, можно пофилософствовать на тему того, что защита анонимного профиля/пользователя тоже предусмотрена, что там может быть амнезия, и его не так-то просто сломать, а даже если сломали, то плохая защита всё равно лучше отсутствия какой бы то ни было, но смысл понятен.


Почему? Кажется, вашим текущим правилам iptables не противоречит тот принцип, что если пакет с dst port = 1723 предназначен компьютеру из локалки, то он пойдёт туда напрямую, а не через VPN. По крайней мере, умолчальная таблица маршрутизации именно такова что до запуска VPN, что после. Эту брешь можно закрыть, поменяв маску сети или вообще сделав «роутинг через сетевой интерфейс» (давно его не тестировал, но раньше он сильно глючно работал).


Это само собой, но есть сайты, которые без скриптов не работают.


Наш ответ Чемберлену. :-)
Извиняюсь за самоподписной сертификат. На других сайтах быстро не смог найти эту же картинку.
— Гость (28/12/2013 02:36)   <#>
Разрешаем юзеру privoxy принимать пакеты на lo на 8118-ой порт

Наверное путаете с pf, в iptables нет owner для входящих пакетов.

Разрешаем юзеру tor_user посылать пакеты на порты 8118 и 9050

Достаточно 8118.

При извратной настройке src IP может не совпадать с IP на интерфейсе, с которого отсылается пакет. Например, в pf во время экспериментов с policy based routing

В предыдущем сообщении про исходящий IP-адрес в цепочке OUTPUT написал неверно, -j LOG показывает что он всё-таки есть. Видимо адрес присваивается при определении маршрута пакета после выхода из процесса.

Насчёт фильтрации по mac-адресу тоже была неточность. Она требует arp-запросов, поэтому при отсутствии фильтра по IP, и наличии по mac, будут arp-утечки. Если фильтраци по IP есть, то arp-утечек не будет, независимо от существования фильтра по mac. Вообще, если срабатывает любая блокировка на верхнем уровне – по протоколу, порту, пользователю или IP-адресу, то фильтр по mac уже не проверяется.

К примеру, у вас клиент по pptp стучится раз в некоторое время, а атакующий заставит его стучаться туда в 10 раз чаще обычного.

Если добавить фильтрацию на lan по пользователю, то не сработает. Все соединения в lan для подключения к Интернету (dhcp и ppp-over-pptp) создаются только рутом, поэтому можно сделать следующее ограничение



Думаю что это концептуально важный момент – выход на физический и виртуальный интерфейсы разрешён разным пользователям: eth0 – root, ppp0 – tor. Поэтому в случае уязвимостей, tor_user внутри системы не сможет послать данные во внутреннюю сеть, т.е. отследить отклик, посылаемый снаружи Тора на локальную машину, во внутренней сети невозможно. Теоретически tor_user может спровоцировать рута на активность в локальной сети, например посыланием фиктивных пакетов в локальные pptp- или dhcp-порты с целью нарушить нормальную работу этих протоколов. Здесь предлагаемая вами фильтрация на lo действительно может оказаться полезной. Да, через Тор можно накладывать отпечаток на трафик, но это атаки другого класса и для противодействия им существуют другие способы, например зашумление. А атаки данного класса – отслеживание сигналов в подконтрольной сети провайдера, инициируемых через Тор-сеть, – отсеиваются фильтрацией исходящего трафика по пользователям.

По поводу фильтрации на lo. При при наличии фильтра на lan и множества возможностей межпроцессного взаимодействия она выглядит как частичное латание возможных дыр. Но сочетание с песочницей создаёт логически законченный подход. Песочница ограничивает доступ процесса к файловой системе, но не доступ к портам. Фильтрация на lo ограничивает доступ к портам, но оставляет полный доступ ко всем файлам системы. Эти два метода дополняют друг друга и возможно создают цельную концепцию.
— Гость (28/12/2013 23:41)   <#>

Да, пока писал первую часть поста, забыл об этой особенности.


Я имел в виду, что некоторые программы под tor_user могут работать с SOCKS напрямую, а другие только с HTTP PROXY. Если программа может работать с SOCKS напрямую, почему бы ей не дать эту возможность?


Пакет должен отправиться на определённый IP, но если MAC-адрес его неизвестен, то компьютер (в любом случае) сначала сделает ARP-запрос, а потом пошлёт пакет или нет в зависимости от того, попадает ли полученный при ARP-запросе MAC-адрес в категорию разрешённых?

Вообще, если что, MAC-адреса можно прописать статически: arp -s. Я себе представлял фильтрацию по MAC-адресам так: все ПК, с которыми мне нужно общаться, я вношу в статическую таблицу (arp -s), а общение со всеми другими MAC-адресами зарезается на корню независимо ни от чего. Правда, я не знаю, как это сделать, т.к. с фильтрацией по MAC-адресам пока не экспериментировал. В Linux это вроде делается, а в BSD по MAC-адресам можно фильтровать только на bridge'ах, поэтому мне неочевидно, можно ли в BSD это сделать вообще (не факт, что добавление фиктивного bridge'а поможет решить проблему), да и на bridge'ах, кажется, только OpenBSD умеет фильтровать.


Здесь я не совсем соглашусь. И я, кстати, вспомнил, почему я изначально написал про утечки по ARP, т.к. это всё же подтверждено какой-то исторической практикой.

Есть такой способ проверки присутствия хоста в локалке: пингуем его, а потом проверяем таблицу: arp -an. Если после пинга он там появился, значит, хост жив, а если нет, то, скорей всего, мёртв (если только там нет фильтрафии по MAC-адресам). При всём этом на пингуемом хосте может стоять сколь угодно блокирующий файерволл, пусть он режет хоть абсолютно весь трафик... но на ARP-запросы он всё равно будет отвечать. Кстати, я не знаю, как запретить ответы на чужие ARP-запросы.

Можно, конечно, сказать, что такой тип «утечек» ничего не даст атакующему анонимных пользователей (ну, разве что я в какой-то момент хочу спрятаться от ISP, убедив его, что меня в сети не было, или я просто боюсь ошибок в ARP-протоколе), но факт остаётся фактом: компьютер посылает те пакеты, которые бы я не хотел, и которые мне совсем не нужны. Это такой своего рода service discovery или avahi, только работающий на нижнем уровне сетевых протоколов.


Никогда не понимал любовь писать DROP/block-правила. Почему бы не сделать DROP всего, а потом дописать ACCEPT на то, что нужно? Очевидно же, что это архитектурно более безопасный подход (хотя и более трудоёмкий, если используется много сервисов).


Зато сможет посылать напрямую в сеть ppp0, которая ничем не хуже: один конец этого VPN'а находится у вас, а другой — у ISP, и ISP прекрасно видит всю левую сетевую активность на ppp0 точно так же, как и на eth0. Т.е., от конкретно моего примера такая модификация защищает, но не защищает от тысяч ему подобных.


Безусловно, но она закрывает очень легко эксплуатируемые дыры. Например, некоторые дыры требуют уязвмости в обоих профилях, чтобы атакующий смог их связать воедино, но другие дыры, такие как, например, нечайно запущенные прокси, отсылающие трафик в сеть напрямую, позволяют легко сделать деанон профиля, даже если уязвим только он один:

  • Этот деанон может быть даже не намеренным, а просто случайным. К примеру, не секрет, что Skype проверяет профиль firefox на предмет используемых проксей (а, возможно, и вывод netstat), чтобы задавать меньше вопросов пользователю и сразу выйти в сеть через прокси в системе, если они используются.1
  • Другой момент — человеческий фактор. Если, к примеру, у вас есть два пользователя, и каждый должен использовать свои порты (или один, например, должен ходить в сеть напрямую, а другой через прокси), то вы можете однажды перепутать настройки. Например, по ошибке напечатать в командной строке
    $ HTTP_PROXY=http://127.0.0.1:8118 wget url
    тогда, когда там реально должно стоять 8119 или когда вообще переменную HTTP_PROXY указывать не надо.2

Правда, если говорить о злонамеренной организации утечек, то их всё равно много, если не используются виртуалки. Простейший пример — посмотреть вывод netstat.3 Если в злополучный момент неанонимный пользователь ходил в сеть на какие-то сервисы, список сервисов будет получен. Далее можно обратиться к администраторам этих сервисов и получить список, кто ими пользовался в нужный момент времени, сильно сузив область поиска. И это одна из причин, из-за которых, если нет виртуалок, лучше во время работы анонимного пользователя не запускать ничего постороннего. Однако, это всё равно плохо, т.к. приводит к дополнительному профилированию (тут уже не знаешь, что хуже).

Вопросы межпроцессорного взаимодействия, если работа не требует подключения к сети, тоже не столь просты. Чтобы минимизировать взаимодействие между профилями, нужно: вырубить все сетевые сервисы; отключить сеть; выдернуть провод; разлогиниться подо всеми пользователями, которые использовались; убедиться через ps aux, что остались только стандартные процессы, запущенные от root'а; подчистить /tmp и /var. После этого можно залогинитьcя и поработать в «безопасном окружении». Чтобы вернуться в обычное окружение, нужно повторить перечисленные выше шаги снова, чтобы гарантировать, что в системе не осталось следов работы того, чтобы запускалось в этом безопасном окружении. И даже тут могут быть какие-то скрытые засады, из-за которых что-то лишнее запишется, к примеру, в тот же /var, а вы этого не заметите, не говоря уже о том, что факт такого логина засвечивается в выводе команды last, которую потом сможет запустить любой пользователь на этом же компьютере. Впрочем, у всех проблем такого рода есть одно простое, но не столь удобное решение — LiveCD.

Ещё одна параноя на тему межпроцессорного взаимодействия — суидные программы. К примеру, у вас нет прав на запись в определённые директории /var, и вы ошибочно считаете, что ничего туда записать не сможете, но тут вдруг оказывается, что вы можете запустить какую-нибудь безобидную утилиту (тот же procmail, например), которая, ВНЕЗАПНО, оказывается суидной и потому может записать файл в /var в ту самую директорию. Я так понимаю, суидна она только для того, чтобы писать туда, в /var. Много ли людей об этих тонкостях знают? Я с этим ознакомился, когда перехимичил с настройками почты, из-за чего она была «утеряна» и не попала в положенное место при скачивании с mail-сервера, но, как позже выяснилось, ничего не потерялось и мирно лежит в /var/log/mail, хотя в норме я туда почту не писал никогда, да и прав на запись у меня там нет. Пример интересен тем, что здесь «отложенное действие» даже не требует запуска локальных сетевых демонов, слушающих на каких-то портах (типа вашего 127.0.0.1:25).


Я не сторонник песочницы, её мы с, я так понимаю, вами уже обсуждали [1], [2]. Конечно, фильтрация пакетов — тоже не SELinux, но тут есть хоть какая-то чёткая градация: нет local root — нет обхода этим способом. Насколько мне известно, для chroot такой гарантии вам никто не даст, не говоря уже о том, что интернет пестрит способами выхода из chroot'а. Кроме того, настройка chroot'а для реалистичных профилей выливается в титаническую сложность4 (это не несколько строк в конфиги iptables добавить), и если так сильно заморачиваться, то, IMHO, лучше не тратить время зря, а сразу настраивать виртуалки, которые одним махом решают куда более широкий класс проблем и даже защищают от локального рута.

Устаревшие инструкции по безопасности были активно в своё время распиарны, попали в официальные хандбуки, рассылки, личные блоги и книги. Если вскормленному на них юзеру вдруг сообщают, что все врут, у него, понятное дело, разрыв шаблона. Да, оказывается, песочницы не предназначены для безопасности, архиектура ПК — для анонимности, а прослушка АНБ — для защиты населения. Что ж, всё когда-то познаётся в первый раз.

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

  1. Подборка рекомендаций в ссылке.
  2. Не держать смонтированным /boot.
  3. Спрятать от самого себя ssh-ключи.
  4. Спрятать от самого себя файл паролей [1], [2].

Список, на самом деле, бесконечен. Про каждую уловку можно сказать, что она закрывает дыру от автоматизированных эксплоитов, поэтому если индивидуальный набор уловок держать в тайне, то можно чувствовать себя в большей безопасности. Другое дело, что это полумера, и решения такого рода не апскейлятся на общепринятые и всем известные. Каждый решает сам для себя, стоит ли с ними связываться, но серьёзно их рекомендовать другим я бы не стал.

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


1Порой доходило до смешного, когда Skype не мог выйти в сеть (хотя выход был напрямую, без проксей), потому что в локальном профиле firefox со старых времён остались прописанными какие-то прокси.
2Из-под неанонимного профиля попытаетесь скачать файл через Tor, которым пользуется анонимный профиль.
3Ну, или сделать нужный syscall к ядру, если на выполнение netstat'а недостаточно прав.
4Примеры по запихиванию Tor'а в chroot (только Tor'а, мы не говорим про TBB, TorBrowser или хотя бы FireFox!). Если хочется зачрутить более реалистичный профиль, чем один процесс под названием Tor, то умножайте длину инструкций на 104 сразу.
— Гость (30/12/2013 03:55)   <#>
Пакет должен отправиться на определённый IP, но если MAC-адрес его неизвестен, то компьютер (в любом случае) сначала сделает ARP-запрос, а потом пошлёт пакет или нет в зависимости от того, попадает ли полученный при ARP-запросе MAC-адрес в категорию разрешённых?

При наличии правила для IP-адреса, проверка по mac-адресу не производится, т.к. решение уже принято. Если пакет разрешён, он спускается вниз по стеку, делается arp-запрос, получается mac-адрес и кадр отсылается в lan. Если пакет запрещён по IP, он уничтожается и никаких дальнейших действий с ним не производится. Это можно проверить пингуя IP-адреса при изменении правил iptables и наблюдая за arp-запросами с помощью tcpdump.

Вообще, если что, MAC-адреса можно прописать статически: arp -s. Я себе представлял фильтрацию по MAC-адресам так: все ПК, с которыми мне нужно общаться, я вношу в статическую таблицу (arp -s), а общение со всеми другими MAC-адресами зарезается на корню независимо ни от чего. Правда, я не знаю, как это сделать, т.к. с фильтрацией по MAC-адресам пока не экспериментировал.

Статическая arp таблица конечно лучше и безопасней (как противодействие arp-спуфингу), но при динамическом назначении IP-адресов не имеет смысла. Когда был другой провайдер со статическими адресами, для фильтрации по mac-адресу просто узнавал его у шлюза (arp 10.x.x.1), т.к. кроме него никто не был нужен, и создавал правило типа этого



При всём этом на пингуемом хосте может стоять сколь угодно блокирующий файерволл, пусть он режет хоть абсолютно весь трафик... но на ARP-запросы он всё равно будет отвечать. Кстати, я не знаю, как запретить ответы на чужие ARP-запросы.

Предполагаю что это можно сделать блокировкой широковещательных запросов (на адреса типа 192.168.1.255). В том числе в одностороннем порядке – разрешить посылать и запретить получать. Хотя возможность запрета на отправку зависит от приложения, которое отсылает данные в сеть (с локальной машины). Например уже упоминалось в этой теме что dhcp клиент открывает "сырой" сокет, который не блокируется iptables.

Никогда не понимал любовь писать DROP/block-правила. Почему бы не сделать DROP всего, а потом дописать ACCEPT на то, что нужно?

В вышеприведённых правилах политика по умолчанию DROP. Первое правило с DROP! uid-owner root идёт для того чтобы в последующих ACCEPT каждый раз не указывать рута.

Зато сможет посылать напрямую в сеть ppp0, которая ничем не хуже: один конец этого VPN'а находится у вас, а другой — у ISP, и ISP прекрасно видит всю левую сетевую активность на ppp0 точно так же, как и на eth0.

На ppp0 идут только пакеты от пользователя tor. Если речь идёт о переключении с Тора на прямое соединение, то оно используется уже другим, неанонимным пользователем. Возможная уязвимость, эксплуатируемая через Тор, локализована в домашнем каталоге tor_user и в сеансе неанонимного пользователя проявляться не должна.

Конечно, фильтрация пакетов — тоже не SELinux, но тут есть хоть какая-то чёткая градация: нет local root — нет обхода этим способом. Насколько мне известно, для chroot такой гарантии вам никто не даст, не говоря уже о том, что интернет пестрит способами выхода из chroot'а. Кроме того, настройка chroot'а для реалистичных профилей выливается в титаническую сложность

Возможно в BSD это так, но в Linux делал chroot для privoxy и tor, ничего титанического в этом нет. Почти все способы выхода из chroot, которые видел в Интернете, основаны на предположении что процесс запущен с правами рута. А если обычный пользователь, то стандартного способа выйти нет, нужно сначала повысить привилегии до рута (получить local root). Так что неочевидно почему выход из chroot легче обхода правил iptables.

К примеру, в Тор-сети появится червь, который сканирует профиль системы (ПО и железо) и отсылает идентификатор в нужное место. Пользователь старательно создаёт профили, цепочки перестраивает, личности меняет. А в итоге все профили сливаются в один потому что Тор имеет полный доступ к файловой системе, которого он не имел бы находясь в chroot.

Виртуальная машина конечно лучше, но по экономичности и простоте не сравнится с песочницей. Например представьте что вам нужно построить безопасный сервис на удалённом VPS. Насчёт Х сервера вы правы – смысла в chroot мало, т.к. для своей работы ему требуется запуск с правами рута.
— Гость (30/12/2013 05:25)   <#>

А как сделать так, чтоб производилась? Использовать ebtables/arptables?


Вспомнил: с вышеупомянутым «роутингом через сетевой интерфейс» я экспериментировал как раз для решения этой задачи. Поскольку маска подсети становится 0xffffffff, диапазон типа 192.168.0.x перестаёт считаться «своей локалкой», поэтому ARP-запросы из этой подсети воспринимаются, как чужие. Соответственно, они туда не отправляются и не посылаются. Ну, а связь с gw зашивается намертво по типу p2p-ассоциации, причём MAC-адрес gw вносится в статическую arp-таблицу. Собственно, всё. Правда, этот финт можно провернуть, как я понимаю, только для одного хоста в локалке в заданном диапазоне адресов (192.168.0/24).


Не совсем. Поскольку физически оборудование ISP не меняется, MAC-адреса на нём, как правило, тоже не меняются, меняются только IP. Если бы можно было независимо объяснить «вот эти MAC-адреса легитимны, а все остальные баним, и это никак не зависит от IP», то было бы отлично. Но стандартный интерфейс arp -s — да, требует указания IP для каждого MAC'а.


Ну вот это как раз плохо. Я выше уже упоминал ссылку «Как правильно писать безопасные правила для файерволлов?». Идём по ней на /comment53159 и видим, что то, что вы предлагаете, нарушает пункт 4. Т.е. затрудняет анализ правил iptables, запутывая их, что с архитектурной точки зрения плохо для безопасности.


А для firefox, для mplayer, для произвольного (и напрёд неизвестного) процесса, который может быть запущен с правами tor_user?


Хорошо. С тем, что local root, в общем случае, не нужен для обхода noexec, вы согласны?


Против червя в Tor'е [1], [2] попытка защиты от такой утечки — фиговый листок. С учётом того, что ему доступны все до одного из ваших запросов в сеть, которые он может тайно (и через сеть Tor же) сливать домой, закрытие доступа к файловой системе мало что меняет. IMHO.


На VPN не пробовал, но на обычной персоналке виртуалки (тот же Xen в Linux, к примеру) устанавливаются несколькими командами. Достаточно один раз разобраться с установкой и настройкой, и потом можно всю жизнь этим средством пользоваться.


В OpenBSD долго ходили слухи про то, что они планируют отвязаться от рута для ключевых сервисов, включая Xenocara (их форк X'ов). Сделали ли они это в итоге — не в курсе. Для sshd вроде сделали, и теперь он у них не от root'а.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3