Что мешает заменить KDE на другую среду? Там что, гвоздями всё прибито?


Можно сделать всё, что угодно, – даже разобрать Whonix по запчастям и собрать самому.


Правила – тут (за исключением того, что по IPv6 ориентируйтесь на это, но лучше всего отключить через grub). Глобально эти вопросы обсуждались в отдельной теме, там же по ссылкам походите.

Правила – тут

Вздыхаю... извиняюсь, но это не правила, не хавту, а просто вольная дискуссия на тему "Как бы можно это сделать" – без тестирования кем-либо, без занесения в аналы pgpru как провереное руководство к действию.
А своей объемистостью оно только страху нагнало.
Из него я понял только то, что задача не такая уж простая, как мне вначале казалось, и кроме pgprubot, никто не пытался сделать надежное проверенное хавту – так получается, что ли?
Тогда я в печали... потому что я не настолько знаток, чтобы переварить это чтиво и сделать надежную инструкцию к действию (и никогда им не стану – я простой пользователь).
Поэтому и пришел сюда за помощью, т.е. за имеющимся конкретным опытом по даннному вопросу (а не за общей теорией).

По поводу отключения поддержки IPv6.
Вы написали, что лучше отключать через grub, а в данной вами ссылке есть такое примечание:

Примечание. Разработчики рекомендуют не отключать IPv6-модуль ядра, наличие которого можно проверить командой:
lsmod | grep ipv6
а применять указанный метод, чтобы избежать получения ошибки от SELinux и других компонентов.

т.е.:

1. Добавить в файл /etc/sysctl.conf следующие строки:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Я затрудняюсь понять, что из них правильнее – отключить в grub или добавить строки в /etc/sysctl.conf

Это how-to с правилами iptables – пошаговое руководство к действию.

Некоторые how-to со страниц Tor Project позже оказались ошибочными – приводящими к утечкам. Всегда есть вероятность никем не замеченной ошибки. Это ещё один аргумент в пользу того, чтобы разобраться с iptables самостоятельно и понять, что делают те или иные правила. Поскольку абсолютной альтернативы Linux, а, следовательно, и iptables, на горизонте не предвидится, это умение полезное, в жизни ещё не раз пригодится.

Да, к сожалению, iptables – это сложно. Это как простенький язык программирования в самых основах изучить. Другие сетевые экраны такого класса тоже непросты. По настройке сетевых экранов пишут целые книжки. Однако, для написания простых правил фильтрации вам нужна лишь пара процентов от возможностей iptables, и эту пару процентов можно легко понять, прочитав пару популярных статей на тему.

How-to под вашу задачу непопулярно. Те, кто начинают так сильно заморачиваться, либо берут готовые решения с уже настроенным сетевым экраном (Tails, Whonix), либо, как минимум, отвязывают Tor Browser от встроенного тора и привязывают его к системному (и уже для такой конфигурации пишут правила iptables). Запирание сетевым экраном конфигурацию по умолчанию (TBB) – неполноценная полумера, хоть она и получила некоторую популярность из-за corridor.

Когда-то с чего-то надо начинать, это не так сложно, это не паяльник с программатором брать в руки. Доверие к посторонним инструкциям без понимания рано или поздно всё равно вас подведёт, какими бы авторитетными эти инструкции ни были.

Даёшь общюю теорию, как написать правила под свой случай – вы требуете готовые пошаговые инструкции, которые можно тупо выполнить без понимания. Даёшь ссылку на такие инструкции – вы начинаете жаловаться, что они слишком сложные, что вы их не понимаете, и, вообще, "а вдруг там ошибки? а можно ли доверять?". Вы определитесь: либо вы включаете голову и самостоятельно пишете правила под свой случай (возможно, разбирая чужие готовые примеры), либо тупо едите то, что вам дают, веря на слово.

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

В порядке убывания надёжности:

1. Убрать поддержку IPv6 из ядра (его придётся перекомпилировать).
2. Выключить на уровне grub на стадии старта системы.
3. Воспользоваться sysctl.conf

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

Я, конечно, не могу оценить корректность этого гигантского скрипта, но меня настораживают следующие комментарии pgprubot:

Я могу, конечно, формально ответить на вопрос, но не думаю, что это поможет делу.
проверил, вроде работает как надо):

(ключевое слово – "вроде")

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

– Какое может быть доверие к скрипту с такими ремарками от самого автора?

Howto – неоднократно проверенно несколькими пользователями конкретное руководство к действию, а это сыроежка.
Конечно, очень нужная и полезная, но в класс howto она еще не попала ввиду причин, указанных абзацем выше.

Даёшь общюю теорию, как написать правила под свой случай – вы требуете готовые пошаговые инструкции,

Так это объяснимо – теории в тырнете полным-полном, а готовых решений для простого пользователя не хватает.

Даёшь ссылку на такие инструкции – вы начинаете жаловаться, что они слишком сложные, что вы их не понимаете, и, вообще, "а вдруг там ошибки? а можно ли доверять?".

И это объяснимо – ввиду причин, только что указанных ("сыроежка").

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

Предостережение было написано на случай использования SELinux. Если вы его не используете, не обращайте внимания.

Всегда использую. Хотя не настраиваю – слишком сложно.

В любом случае, это не прибивание гвоздями: будут проблемы – вернёте назад, как было.

Хотелось бы без лишних экспериментов, т.е. знать заранее, что лучше.

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

Давно определился :) Хотя в Линуксе не один десяток лет, но знаю его на уровне простого пользователя, и из этой ниши никогда не выйду – способности не те.
Но это же не мешает мне оставаться продвинутым пользовтаелем, не залезая в дебри глубоких теорий?

Поэтому да – доверяю чужим решениям, но не тупо, как вы попыталсь пристегнуть "тупо" + едите".
Я доверяю чужим решениям, основываясь на репутации их создателей, массовости использования и тестов.

Вы же не разбираете Linux по косточкам, тем не менее пользуетесь им? Вот и я также.

Это я ответил на ваши вопросы. И спасибо, что подерживаете эту тему.
Теперь немного впечатлений по скрипту от pgprubot.
Когда-то я пытался осилить iptables, но его сложность оказалось не для моего ума.
Пытался еще использовать к нему фронтенды, ноони создавли такое месиво, что отказался от их использования.
Тем не менее какие-то совсем миниммальные навыки сохранились, которые позволяют копировать iptables с компьютера на компьютер, открывая нужные порты, и для большинства типичных простых задач хатало.
Tor, если судить по скрипту от pgprubot – это не простой случай, но все равно меня не покидает удивление, почему скрипт так сложен.

Ведь на первый взляд кажется так: запереть все порты на вход и на выход, оставив на выход только один 9150.
И такое решение по идее должно быть простейшим. Но решение от pgprubot это опровергает.
Где же я ошибаюсь?

Это вы гигантских скриптов на сотни и тысячи строк не видели со своими библиотеками. За вычетом определения переменных и установки стандартных политик там всего 17 правил, и все элементарные.

Эта ремарка касается всего вместе (настройка TBB, iptables и всего остального) на безопасный режим, а не одних только правил iptables.

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

Готовое решение для простого пользователя – это Tails. Одного iptables всё равно будет мало для безопасной настройки системы.

А вывод какой? Всё тот же: либо едим, что дают, либо сами становимся "знатоками" и перепроверяем чужие решения. Как промежуточный вариант – платим тому, кому доверяем, и кто может перепроверить за нас. Правда, тут всё равно остаётся проблема, кому доверять, – чтобы правильно ответить на этот вопрос, нужно самому быть "знатоком". Круг замкнулся.

Что касается конкретно iptables, он не может сделать хуже, чем полное отсутствие сетевого экрана. Дополнительные некорректные правила могут закрыть не все дыры из имеющихся, но iptables не открывает никаких новых дыр относительно полностью открытой системы. Если у вас сейчас нет никакого сетевого экрана, скрипт не сделает хуже – это точно.

Понять готовый скрипт iptables, в котором нет ничего, кроме примитивных правил фильтрации, не под силу "продвинутому" пользователю? Да ну?

Tails – массовое решение? Казалось бы, да. Однако, это не помешало найти там проблему в правилах iptables, из-за которой трафик мог идти в обход Tor. Всему виной i2p, трафик для которого они не достаточно аккуратно и параноидально описали в правилах. Если делаешь решение для себя, нет необходимости тащить туда всё, что может понадобиться среднестатистическому пользователю – как итог, правила получаются более простыми и надёжными, чем чьё-то монстроидальное, но массовое решение.

Правила для прозрачного проксирования трафика через тор много лет висели на страницах Tor Project, пока однажды сами же члены TP не нашли в них нетривиальную дыру. Массовость – это обычно палка в двух концах. С одной стороны, массовое решение "проверенное", с другой – это сам по себе монстр, от которого вам нужна лишь малая часть его возможностей. Одно играет на руку безопасности, другое – наоборот.

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

А что сложного в базовых правилах? Перечисляется, с какого интерфейса, с какого IP, по какому протоколу и на какой (какие) IP и порт можно посылать пакеты, а на какие нельзя. Можно – ACCEPT, нельзя – DROP. Каждый пакет проходит правила попорядку сверху вниз пока не дойдёт до того, которое подходит под его критерии, определяя его в ACCEPT или DROP.

Тогда я тем более не понимаю, в чём проблема. Скрипт элементарен.

Может быть, дело не в Tor, а в том, что там гайки затянуты в скрипте, хотя обычно их никто не затягивает?

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

# 5 следующих строк отредактировать под свой случай: MY_IP_ADDRESS=10.20.30.40 MY_NETWORK=10.20.30.0/24 MY_INTERFACE=eth0 TOR_USER=tor FIREFOX_USER=your_user iptables -F iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP

Это стандартная шапка: определение переменных, сброс всех ранее загруженных правил, выставление политики по умолчанию в DROP (всё, что не разрешено, запрещено).

iptables -A OUTPUT -p udplite -j DROP iptables -A OUTPUT -p esp -j DROP iptables -A OUTPUT -p ah -j DROP iptables -A OUTPUT -p sctp -j DROP iptables -A OUTPUT -o lo -p tcp -j DROP iptables -A OUTPUT -o lo -p udp -j DROP iptables -A OUTPUT -o lo -p icmp -j DROP iptables -A OUTPUT -o $MY_INTERFACE -p tcp -j DROP iptables -A OUTPUT -o $MY_INTERFACE -p udp -j DROP iptables -A OUTPUT -o $MY_INTERFACE -p icmp -j DROP

Эти правила можно не писать, но вам же интересно было бы узнать, что какое-то приложение попыталось выйти в обход тора и дать утечку? Такой трафик блокируется, и в iptables-save -c будет идти счётчиком пакетов в DROP. Однако, его можно дополнительно блокировать принудительно, и тогда iptables-save -c покажет счётчик пакетов напротив каждого из правил. Вы увидите, на каком интерфейсе и по какому протоколу кто-то захотел выйти в сеть. Для более редких протоколов – только по какому протоколу (без интерфейса). В общем, тут можно нагородить, как пожелаете. В идеале ставят просто логирование и сохраняют такие пакеты или их метаданные в сторонний файл, который потом можно проанализировать, указав достаточно точные причины попыток прорваться наружу: какой юзер, в какое время, с какого интерфейса, на какой IP, по какому протоколу, и что он вообще хотел. Соотнося это с другими системными логами можно выяснить, почему так произошло (например – вы запустили приложение, дающее утечки по DNS, и система в логах вам просигнализировала об этом).

Но вернёмся к тому, с чего начали: всё это опционально. Можно ничего не знать и не анализировать, а тихо блокировать, тогда эти правила писать не нужно.

Пока думал, что значат другие правила, увидел, что не приметил слона: они написаны не под ваш случай. Там пример системного тора + выход TBB (или firefox) через системный тор, где системный тор запущен от служебного пользователя, а пользователь браузера – это другой. Т.е. речь о более-менее рекомендуемой стандартной настройке.

Ваш случай (один только портабл TBB без системного тора) с помощью iptables вообще толком не решается, потому что система не может различить трафик тор-демона от трафика браузера (или иного трояна), потому что они оба запущены под одним пользователем, а сетевой экран сортирует трафик только по пользователям (не но по приложениям). Полумеры здесь – либо ограничивать соединения с сетью списком ваших конкретных guard-узлов, либо всей тор-сетью. Первый вариант нестабилен в работе, потому что guard-узлы периодически меняются. Он, возможно, подходит только тем, кто прописывает guard-узлы вручную в torrc. Второй вариант, в общем-то, решаем, но чтобы ограничить соединения тор-сетью, нужно уметь парсить списки всех нод сети и их портов – примерно так. Однако, толку от этого всё равно мало, потому что атакующий просто поднимет подконтрольную ноду в сети, и при деаононимизации будет слать на неё специфический трафик – iptables этот вариант отловить не сможет.

Одним словом, как ни крутись, если что-либо предпринимать, лучше поставить системный тор и отвязать TBB от встроенного тора. В этом случае задача решаема указанным вам скриптом. Всё остальное – пляскок не меньше, а дыры останутся почти теми же.

Внимательно прочел ваше эссе, спасибо! Интересно пишете, однако :)
Когда читал, понемногу формировалось решение, и когда дочитал до конца, оказалось, что оно практически совпало с вашим :)) Т.е. – использовать системный Tor.
Более того – решил вернуться к рекомендованному ранее проекту Onion Pi, учитывая его недостатки, описаные выше.

Просьба подсказать по выбору компонент:

1. Покупать готовый набор за $69.95 с вшитым Тором заманчиво (поскольку работает формула "Купил-Воткнул-Работает!"), но в ближайшей лавке такое не продают, а заказывать из-за бугра это много возни и ехать будет долго, поэтому – соберу и залью сам.

2. Однако самосбор порождает другую проблему – рекомендованных устаревших моделей Raspberry Pi 1-й тихоходной версии B+ (или просто B) уже так просто не найти, или будет задорого.
Поэтому остается 2-я или 3-я модель.

3. И тут вопрос – какую лучше взять – 2-ю или 3-ю?
3-я пошустрее будет, и WiFi уже на борту. Но – зачем Tor эта шустрость, если она напрямую связана с настолько повышенной прожорливостью, что к этой "малине" нужен радиатор и даже кулер?
Ведь с Tor справлялась даже "малина" 1-й версии.
Или же эта "малина" потребляет эту высокую мощность только при высокой загрузке?
В таком случае хотелось бы знать, насколько загружает "малину" наш Tor – сильно или не очень?

4. И если же энергопотребеление "малины" 3-й версии при работе Tor будет таким же, как у 1-й, тогда можно не париться с розысками устаревших версий и взять нынешнюю 3-ю.

5. И в этих "малинах" вообще как принято – если в 3-ю встроили WiFi-чип, то его поддержка в системе уже есть готовая, или где-то надо разыскивать на него драйвера?
Просто еще ни разу не работал с Raspberry, опыта нет совсем.

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

Я бы и обычное железо не советовал заказывать, а такое специализированное – тем более. Шансы нарваться на такую штуку велики. Если покупать специализированное, то только лично из рук продавца-изготовителя. Если покупать иное простое железо – то анонимно в любом обычном магазине, не сообщая своих данных. Почтовые заказы и пересылки – прямой путь к получению имплантов.

Где-то писалось про проблемы с тор-нодами, запущенными на RP, где из-за DDoS они начали массово выходить из строя. Обычных тор-шлюзов это касаться не должно, тор ест мало ресурсов. Минимального железа должно хватать.

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

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

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

Я бы и обычное железо не советовал заказывать, а такое специализированное – тем более. Шансы нарваться на такую штуку велики.

Я бы выразился более грубо: в нашу продвинутую эру в каждое устройство и достаточно объемистый софт уже заложена та или иная закладка, а то и целая коллекция.
Но делать для кого-то специально закладку? Если бы я был, скажем, вице-премьером и заказал какой-то дивайс на свое имя, то ясное дело, призводитель за сутки нашпиговал бы спецэкземпляр уймой закладок и выслал бы в кратчайшие сроки, пока я не передумал – на, пользуйся, дарагой медвэд!
Но поскольку речь идет о скромной никому неизвестной персоне, то никто этой затратной фигней маяться не будет – просто всю партию устройств заранее обеспечат дежурными закладками, а дальше останется только ловить рыбку в мутной воде тырнета.
В любом случае я не питаю никаких иллюзий относительно защищенности своих решений и реализации 100% безопасности – это миф! Закладки заложены еще на докомпиляторном уровне, и просмотр исходников – это народная забава для "икспертов по безопасности".

Как известно, все тайное рано или поздно становится явным.
И безопасность, что тоже известно, это не результат, а непрерывный процесс, как борьба с ветряными мельницами :)
Но слегка сузить круг соглядатаев – это возможно, что я и пытаюсь сделать.

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

Прикиньте, хотя бы примерно, с каким количеством разных людей вы говорили по телефону за последние полгода? 50? 100? 300? Ну пусть даже 50. Вероятно, и каждый из миллиона прослушиваемых — тоже. У телефонного разговора же две стороны. Так что в 2015 году, вероятно, несколько десятков миллионов человек были участником хотя бы одного прослушиваемого телефонного разговора.

Все персоны, которые так заморочились безопасностью и анонимностью, что пошли покупать специализированные хардварные решения – очень интересные люди

Откуда же им известно, что "малина" куплена для Тора? Может, я на ней, как многие сейчас ударились в это, компактный видеоплеер собираю. К тому же "малину" уже трудно назвать специализированным решением, на ней сейчас городят что угодно, даже такие примитивные задачки, управление оконными жалюзями (блин, мало им Ардуино).

найдётся очень много желающих за ними присмотреть и выяснить, что они там прячат за тором.

Максимум, что они узнают – так это упрутся в аппаратный файрволл, а то и не один – цепочку :)

Мимиходом: с каждым годом у меня крепнет впечатление, что эпоха защиты от вторжений извне (весьма затяжная) довольно успешна решена и ее острота постепенно иссякла, и на первый план выходит защита от "проблемы наоборот" – собственных утечек.
И вот тут, кмк, радикального решения без своего соственного железа и софта пока нет.

В-общем, решение принято, "малина" в дороге, в ближайшеее время ждите впечатлений и вопросов :)

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

Встроив бэкдор-имплант в RP, который заворачивает ваш нешифрованный трафик в тор, они узнают всё.

Вторжения извне обычно происходят при активной поддержке изнутри, будь то социнжиниринг или предустановленные бэкдоры. Достаточно почитать, как АНБ ломает сети.

Встроив бэкдор-имплант в RP, который заворачивает ваш нешифрованный трафик в тор, они узнают всё.

Это да. Гарантированной защиты нет. Надеюсь лишь на, что в RP еще не успели встроить закладки, тогда как в каждой материнской плате, а то и в процессоре, убежден, они всегда есть.
Наверное, вероятность закладок минимальна в первых версиях RP, когда разработчики еще не ожидали такого громкого успеха своего устройства. На все последующие АНБ наверняка наложило свою лапу.

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

Ещё на стадии выхода на рынок железо, используемое в RP, было раскритиковано за множество закрытой фирмвари.

Дааааа, Гость_, умеете вы оптимизм вселять ;)
Вы почти загнали меня в угол.
Впрочем – я там мало что понял: сначало кто-то кого-то непонятно за что-то проклял, а дальше все потонуло в местных идиоматических выражениях :-P

В любом случае защита хоть на малине, хоть на клубнике это лучше, чем ничего. Идеальной-то все равно нет.
К тому же вроде ничего не мешает установить на "малину" тот же Whonix – и все на выходе равно получим ту же крохотную коробочку с голубой каемочкой ;)

Здесь чуть подробнее, ну, и ранее понемногу упоминалось.

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

Gateway в Whonix должен быть доверяемым как в плане софта, так и железа. Не путайте с workstation. Установкой на RP Wnonix-gateway вы никак не нейтрализуете те баги, которые в RP есть. Они ограниченно нейтрализуются, только когда прячете это железо за ещё один внешний роутер.