iptables --gid-owner работает только для основной группы пользователей
Я пытаюсь отключить доступ к IP 1.2.3.4 для всех пользователей, кроме членов группы "Нета". Это новая группа, которую я создал только для этого вопроса.
iptables -I OUTPUT -o eth0 -p tcp -d 1.2.3.4 -m owner ! --gid-owner neta -j REJECT
Это отключает доступ к 1.2.3.4 для всех пользователей, даже если они являются членами группы "neta".
У меня есть пользователь xx, и он является членом групп xx (основная группа) и neta. Если я изменю правило на:
iptables -I OUTPUT -o eth0 -p tcp -d 1.2.3.4 -m owner \! --gid-owner xx -j REJECT
все, кроме пользователя xx, не могут получить доступ к 1.2.3.4.
Я добавил root в эту группу xx:
usermod -a -G xx root
но root все еще не мог получить доступ к этому IP. Если я добавлю группу основного пользователя (root, xx) к правилу, все будет работать как положено.
Я попытался разделить его на два правила, чтобы быть уверенным (и журнал отклонен):
iptables -A OUTPUT -o eth0 -p tcp -d 1.2.3.4 -m owner --gid-owner neta -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -d 1.2.3.4 -m limit --limit 2/s --limit-burst 10 -j LOG
iptables -A OUTPUT -o eth0 -p tcp -d 1.2.3.4 -j REJECT
но разницы нет. Все отвергается.
Других правил iptables нет.
root@vm1:~# iptables -nvL
Chain INPUT (policy ACCEPT 19 packets, 1420 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 10 packets, 1720 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 1.2.3.4 owner GID match 1001
0 0 LOG tcp -- * eth0 0.0.0.0/0 1.2.3.4 limit: avg 2/sec burst 10 LOG flags 0 level 4
0 0 REJECT tcp -- * eth0 0.0.0.0/0 1.2.3.4 reject-with icmp-port-unreachable
Я хочу иметь возможность (де) разрешать доступ к этому IP-адресу, добавляя / удаляя пользователей из этой группы "neta" вместо добавления правил iptables для каждого пользователя.
3 ответа
Хорошо, честно говоря, я немного знаю о linux и iptables, чтобы быть уверенным в моей теории, но так как я хотел сделать то же самое для VPN, мы идем.
Я предполагаю, что сопоставление выполняется с использованием процесса, из которого происходят пакеты, и что процесс linux не получает все группы назначенного пользователя, а вместо этого процесс выполняется с одним uid и одним gid.
Это означает, что вы должны выполнить команду явно, используя эту конкретную группу, иначе команда / процесс выполняется с использованием группы пользователя по умолчанию.
Написание этого у меня была идея, чтобы увидеть, есть ли такая возможность. Я ограничил доступ к определенному диапазону IP, используя группу VPN. Это никогда не работало. Теперь я проверил с помощью следующей команды, и она работает:
sg vpn -c "ssh user@10.15.1.1"
Поэтому я надеюсь, что моя теория была верна.
Старый пост, но, как я уже говорил, я столкнулся с этой проблемой на сервере Ubuntu 16.04.3 LTS.
Реализация расширений iptables в Ubuntu через netfilter проверяет владельца текущего сетевого пакета и запрашивает только основной идентификатор группы этого пользователя. Это не копает глубже и получить все членство в группах. Только основная группа сравнивается с --gid-owner
значение. Это не выглядит дальше.
То, что ОП пытался выполнить, сработало бы, если бы он / она изменил основную / стандартную группу пользователей всех соответствующих имен пользователей на "neta". Эти пользователи будут затем захвачены правилом.
Чтобы использовать дополнительную группу, вам нужно добавить флаг в команду iptables.
Со страницы руководства:
--suppl-groups
Группа(ы) причин, указанные с помощью
--gid-owner
также проверяться в дополнительных группах процесса.