to Yustas
1. Для приложений не получится. Повторюсь, netfilter (подсистема фильтрации в составе ядра Linux) и его командные интерпретаторы (iptables) или GUI-интерфейсы (UFW) не оперируют запущенными программами/приложениями. Раньше в iptables был параметр
-m owner --pid-owner PID, где PID - номер процесса (потока), назначаемый каждому запущенному приложению (просмотр через ps ax | grep имя_приложения). Но позже его убрали, посчитав избыточным. Плюс, это порождало бы проблемы при отлавливании PID для комплексных приложений (тот же firefox создает дополнительный процесс для каждой открытой вкладки браузера)...
2. Можно использовать вашу схему с группами или аналогичную схему с фейк-юзерами как
тут (конец поста). Но у меня на Linux Mint это не заработало, в AL
SE тоже. Беда (отказ в доступе) в запуске графических приложений (которым нужен доступ к X-Server) из-под фейк-юзера, когда X-сессия запущена моим штатным пользователем. С группами проблема примерно аналогичная. Возможно, в AL
CE разграничений меньше, поэтому там схема с группами сработает - не проверял, ибо не пользуюсь...
3. Не делайте "
OUTPUT -m state --state ESTABLISHED,RELATED" - это поддержка "сессии" (по умолчанию, netfilter сессии не поддерживает). Грубо говоря, если добавлено такое правило, то на каждый разрешенный входящий (цепочка
filter -
INPUT) пакет netfilter будет автоматически добавлять разрешение исходящего (цепочка
filter -
OUTPUT) трафика. И, если у вас не сервер с работающим приложением, доступ к которому нужен извне, то вам такое (ESTABLISHED,RELATED) не нужно...
4. Отбивка "
-j REJECT --reject-with tcp-reset" не вяжется с желанием "невидимости". Потому что при любой опции
REJECT netfilter будет отправлять адресату уведомление о блокированном пакете в рамках выбранного протокола. И в цепочке OUTPUT (исходящие от вашей машины) это тем более смысла не имеет. В наше неспокойное время куда проще делать тупо "
-j DROP". Опять-таки, если у вас не сервер, доступный извне и стремящийся уведомить удаленных пользователей о своей принципиальной доступности, но неправильном трафике, который они к нему шлют...
5. С MiTM и подменой DNS средствами netfilter вы почти ничего не сделаете. Можно, конечно, контролировать целостность и состояние каждого пакета, логировать их, натравливать на лог какое-либо средство высокоуровневого анализа, выявлять аномалии по меткам приходящих ответов (например, искажения TTL и других полей L2, L3, L4 уровней), но... MiTM тем и отличается, что при пассивном методе (перехват и анализ трафика) узнать о нем на стороне источника (ваша машина) фактически невозможно. Или мы говорим о другом MiTM (например, подмена SSL-сертификата провайдером или кем-то еще)?. Вариантов слишком много и, что печально, защититься от них полностью столь примитивными инструментами как netfilter/iptables не получится...
ЗЫ Outpost Firewall был когда-то хорош. Но от MiTM на канале, от перехвата и манипуляции с DNS (или внедрения ложного DNS-сервера на канале) и т.п. он тоже не защищал ни разу...