В Таким образом, текущая политика в моей системе для изменения имени хоста А кто такой администратор, чей пароль может разрешить эти действия? В моей системе Debian 9 это определяется файлами в каталоге Если вам не нравится эта политика, вы можете легко изменить ее, написав несколько пользовательских файлов конфигурации PolicyKit. PolicyKit можно настроить так, чтобы он требовал любых следующих «уровней безопасности» для любого управляемого им действия: Время сохранения В настоящее время, по-видимому, нет никаких средств для настройки этого значения во время выполнения -, а также для продления метки времени аутентификации -после ее установки. Похоже, что OpenSuSE расширил это с помощью результатов systemd
и связанных утилитах действия, которые могут потребовать привилегированного доступа, направляются через PolicyKit. Запустите pkaction
без каких-либо параметров, чтобы увидеть список всех возможных действий, обрабатываемых PolicyKit. Чтобы увидеть текущую политику для определенного действия, используйте pkaction --verbose --action-id
# pkaction | grep host
org.freedesktop.hostname1.set-hostname
org.freedesktop.hostname1.set-machine-info
org.freedesktop.hostname1.set-static-hostname
# pkaction --verbose --action-id org.freedesktop.hostname1.set-hostname
org.freedesktop.hostname1.set-hostname:
description: Set host name
message: Authentication is required to set the local host name.
vendor: The systemd Project
vendor_url: http://www.freedesktop.org/wiki/Software/systemd
icon:
implicit any: auth_admin_keep
implicit inactive: auth_admin_keep
implicit active: auth_admin_keep
auth_admin_keep
-, то есть требуется пароль администратора , если только пользователь совсем недавно успешно не прошел аналогичную проверку (, точно так же, как sudo
можно избежать последовательных запросов пароля ). /etc/polkit-1/localauthority.conf.d/
-по умолчанию, только root и члены группы пользователей sudo
. yes
-пользователь всегда может это сделать, не задавая вопросов auth_self_keep
-Если пользователь в последнее время не делал ничего, требующего проверки пароля, запросите пароль пользователя, чтобы убедиться, что это действительно он/она. Если в течение нескольких -минут выполняется несколько последовательных действий этого уровня, проверки могут быть пропущены после первой.auth_self
-всегда требовать проверки пароля пользователя auth_admin_keep
-требуется пароль администратора. Так же, как и auth_self_keep
, после однократного ввода пароля (и, возможно, имени администратора ), пользователь может выполнять несколько действий этого уровня в течение короткого промежутка времени без дополнительных запросов пароля auth_admin
-всегда требуется проверка пароля, и пользователь, отвечающий на проверку пароля, должен быть одним из пользователей с правами администратора no
-Действие отклонено без дальнейших вопросов. ..._keep
результатов явно жестко -закодировано в исходном коде PolicyKit:вот ссылка на PolicyKit Git./* TODO: right now the time the temporary authorization is kept is hard-coded - we
* could make it a propery on the PolkitBackendInteractiveAuthority class (so
* the local authority could read it from a config file) or a vfunc
* (so the local authority could read it from an annotation on the action).
*/
expiration_seconds = 5 * 60;
...keep_session
и ...keep_always
. По-видимому, они также переосмыслили действия ...keep
, чтобы они означали «запоминать результат до тех пор, пока продолжается процесс запроса».
Начиная с Linux 4.7 в 2016 году, автоматическое назначение помощника conntrack было отключено по умолчанию (после нескольких лет предупреждений об этом в сообщениях ядра):
Four years ago we introduced a new sysctl knob to disable automatic helper assignment in 72110dfaa907 ("netfilter: nf_ct_helper: disable automatic helper assignment"). This knob kept this behaviour enabled by default to remain conservative.
This measure was introduced to provide a secure way to configure iptables and connection tracking helpers through explicit rules.
Хотя вернуться к незащищенной -версии несложно, я бы предпочел дать ответ, используя новый метод, используя iptables(nftables , которые тоже могут это сделать,с небольшими различиями в приоритетах цепочки ). Как это сделать описано в этом блоге:Безопасное использование iptables и помощников по отслеживанию соединений .
Итак, следуя приведенной там информации, это должно быть сделано на маршрутизаторе, использующем NAT:
большое предупреждение:
Вспомогательный модуль должен существовать и иметь возможность автоматически -загружаться перед правилом, ссылающимся на него в необработанной таблице, иначе добавление правила завершится ошибкой. Это может даже помешать правильной работе iptables-restore
и оставить брандмауэр без каких-либо правил при загрузке.
В любом случае часть NAT модуля (здесьnf_nat_tftp
)не будет загружаться автоматически -. Так что в любом случае лучше загружать этот модуль явно при загрузке системы, как это сделал OP.
предполагая, что теперь это значение по умолчанию или уже было сделано:
# sysctl -w net.netfilter.nf_conntrack_helper=0
явное объявление местоположения помощника, где селекторы здесь имитируют те, которые используются в OP's POSTROUTING (с использованием точного и уникального IP-адреса TFTP-сервера):
iptables -A PREROUTING -t raw -p udp --dport 69 -s 192.168.11.0/24 -d 172.16.0.0/16 -j CT --helper tftp
Само по себе это правило теперь должно активировать помощника, когда это необходимо, что инициирует изменение данных и портов TFTP, поскольку TFTP — это сложный протокол, в котором ответы сервера могут возвращаться с несвязанных исходных портов на динамический/эфемерный исходный порт клиента., как показано в этой статье Википедии для TFTP .
явно принимать общий установленный трафик, связанный трафик tftp и начальные запросы TFTP:
Поскольку вы уже ПРИНИМАЕТЕ все, что исходит из eno1 и поступает в , эти правила бесполезны для вашей текущей конфигурации. Если вы решите ужесточить правила брандмауэра, вот они. Вы можете сделать их более или менее тесными (, добавить интерфейсы и т. д.):
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED -m helper --helper tftp -s 172.16.0.0/16 -d 192.168.11.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.11.0/24 -d 172.16.0.0/16 -p udp --dport 69 -j ACCEPT
Второе правило разрешает эти TFTP -обратные соединения от сервера к клиенту (, следовательно, обратные направления )до того, как ответы будут УСТАНОВЛЕНЫ. Цепочка FORWARD видит не -NAT-трафик, поэтому ей не нужно знать, что произошло во время MASQUERADE (, хотя там вмешался помощник tftp ).