Что запускается первым?

Question

[vitaliy_saveliev]

День добрый, уважаемые Пользователи Тостер.ру!

Сегодня увидел непривычный для меня финт ушами:
вначале запускать скрипт правил iptables, а потом писать единичку в /proc/sys/net/ipv4/ip_forward

человек, который так сделал объяснил это так: мол при таком подходе появляется гарантия того, что форвард не включится без правил фаервола

раньше я делал так: правил /etc/sysctl.conf + сохранял правила таким образом: service iptablespersistent save (debian) или service iptables save (centos)

собственно сам вопрос: реальна ли атака(форвард на другой интерфейс) при моем подходе при включении сервера?

Answer 1

[Дмитрий Филимонов]

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

Но можно усугубить: если вы используйте conntrack в FORWARD вместе с правилом

iptables -I FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

то потенциально возможен случай, когда соединение установится до загрузки iptables, а позже, когда iptables загрузит правила, соединение пойдет по этому правилу. Но ведь это редкость, когда кто-то использует conntrack в FORWARD, да еще и с пропуском всех установленных/связанных соединений. Обычно такое актуально для INPUT у серверов, но уж точно никак для FORWARD.

Так вот, если у вас все правильно, вы не используйте conntrack с этой конструкцией для FORWARD, по умолчанию политика для FORWARD является DROP, и вы там строго контролируете, что куда в какие стороны по сетям, то нет повода для паники. Все равно все неправомерные соединения дропнутся после инициализации iptables, а время до загрузки iptables вряд ли критично, хотя лучше грузить его пораньше, конечно. Причем это некритично для systemd, например, ибо он параллельный и асинхронный (или для многих других init-систем).

Других случаев я не придумал.

В качестве вывода: опуская паранойю и ESTABLISHED/RELATED ACCEPT в FORWARD, атака нереальна.

Answer 2

[Владимир]

в Debian iptables-persistent стартует раньше procps
в нем не проскочат

за CentOS не скажу (давно повывелась)

Comments

[Дмитрий Филимонов]

Ян Ко: дополню чуток.

7 центось. Сетевые интерфейсы (говорю за initscripts) инициализацируются раньше basic.taget, в котором находится iptables. В свою очередь sysinit.target, где systemd-sysctl, стартует позже basic.target. С NetworkManager не смотрел, но сути вряд ли поменяет, ведь главное, что sysctl вступит в силу после iptables.

Посмотрел также на archlinux, там такая же картина, просто все раскидано в немного другие таргеты.

Склонен думать, что так на всех systemd-based, ибо это поведение напоминает стандартное.

В остальных, особенно в bsd-like (crux, slackware), лучше все проверить, думаю, возможны разные варианты :)

Answer 3

[mureevms]

В общем случае да. И дело не в другом интерфейсе, а во всем, что за ним, как правило это локальная сеть.
Но счет идет на доли секунд-несколько секунд - от момента загрузки ядра до срабатывания правила iptables -P FORWARD DROP, если оно есть. И может проявиться только при перезапуске скрипта фаервола или рестарте сервера. К тому же, если скрипт перезапускается, то форвард в ядре уже разрешен предыдущим запуском скрипта, поэтому, такой "финт" отрабатывает только один раз при загрузке системы.
Если же в дефолт полиси вместо DROP ACCEPT, то и нет особого смысла включать маршрутизацию в ядре после отработки правил фаера. Хотя, это зависит от количества правил и речь там идет о времени, которое необходимо на отработку самих этих правил.