Назад | Перейти на главную страницу

Правила стиля Cisco ACL для IP-таблиц на маршрутизаторе Linux

Когда дело касается маршрутизаторов, у меня больше опыта работы с Cisco, чем с Linux. При разработке правил брандмауэра я привык думать о in наш out ACL привязаны к определенным интерфейсам.

Я думаю, что могу имитировать это поведение с помощью таблиц IP, заставив цепочку FORWARD перейти к настраиваемой цепочке для каждого интерфейса.

Например (политики по умолчанию будут DROP): 

iptables -N INET_IN
iptables -A FORWARD -i eth0 -j INET_IN
iptables -A INET_IN -m tcp -p tcp --dport 80 -d 12.12.12.12 -j ACCEPT

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

  1. Есть ли причина, по которой это может вызвать у меня проблемы или просто не работать?
  2. Если это сработает, разве это не способ сделать это и мне нужно перевоспитание?

В конечном счете, структура цепочки iptables - это сочетание личных предпочтений и использования функциональности. Я пришел к этому прямо противоположно, например, как вы. Я люблю "метафору" iptables и ненавижу метафору Cisco ACL. Мне нравится думать о диалогах с отслеживанием состояния, а не о потоках пакетов. (Если мне нужно выбирать между Cisco PIX или маршрутизатором с набором функций межсетевого экрана или iptables, с точки зрения удовольствия от администрирования, я бы взял iptables в любой день ...)

Фраза «Я, вероятно, буду использовать проверку с отслеживанием состояния ...» немного сбивает с толку. Netfilter - это фильтр пакетов с отслеживанием состояния. Вы можете написать набор правил, который работает с его «сохранением состояния», но это будет контрпродуктивно. Я обнаружил, что писать правила, основанные на установлении соединений, намного приятнее, чем пытаться написать необходимые правила и «зеркальные» правила для управления трафиком без сохранения состояния.

Вы хотите, чтобы пакет проходил как можно меньше цепочек и как можно меньше правил. Начиная цепочки "фильтровальных" таблиц с -m state --state RELATED,ESTABLISHED -j ACCEPT позволит механизму проверки состояния проталкивать пакеты для уже установленных соединений через набор правил, не пересекая всю цепочку.

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