Для перемещения по дереву справки используйте строки заголовка.

Справка по NSG Linux 2.1.3
Дерево команд: ip.filter.…далее…

Что это такое?

Это настройка фильтров IP-пакетов.

Зачем это нужно?

Как это настроить?

Фильтрация пакетов в ОС Linux является частным случаем механизма netfilter, работающего в ядре Linux. Настройка этого механизма производится с помощью утилиты iptables. Узлы nat, filter, mangle и raw конфигурационного дерева NSG являются оболочкой к данной утилите. Подробно обо всех их возможностях и настройках см. первоисточник, т.е. man pages по iptables в оригинале. Настоятельно рекомендуется ознакомиться с этим документом хотя бы по диагонали, чтобы получить представление об общей структуре настроек.

Говоря коротко, настройка iptables производится в виде таблиц с именами nat, filter mangle и raw, соответственно. Каждая таблица состоит из цепочек последовательно выполняемых правил. На разных этапах обработки пакета в системе используются различные предопределённые цепочки и, кроме того, пользователь может создавать и подключать свои собственные цепочки по своему усмотрению.

Этапы обработки пакетов на сетевом уровне - фильтрация пакетов.

ПРИМЕЧАНИЕ. Многие действия (например, уничтожение пакета) могут, вообще говоря, выполняться в схожих цепочках, принадлежащих к разным таблицам. Однако для правильного понимания конфигурации принято разделять их по существу: преобразования адресов и портов — в таблицу nat, фильтрацию и подсчёт пакетов — в таблицу filter, всё прочее — в mangle. Как минимум, это помогает избежать человеческих ошибок. Извращённые ситуации, когда требуется выполнять эти операции в ином порядке, нежели указано на схеме, теоретически возможны, но на практике крайне редки.

Таблица фильтров в устройствах NSG включает в себя следующие цепочки:

INPUT
Для пакетов, адресованных локальным службам и приложениям на данном устройстве. Применяется после nat PREROUTING.
OUTPUT
Для пакетов, генерируемых локальными службами и приложениями на данном устройстве. Применяется после nat OUTPUT.
FORWARD
Для транзитных пакетов, передаваемых с одного стороннего хоста на другой через данное устройство. Применяется в процессе маршрутизации — после nat PREROUTING и до nat POSTROUTING.
UPnP
Разрешающие фильтры IPv4, автоматически сформированные при работе службы UPnP для пробрасываемых портов. Вызываются из цепочки FORWARD; если пакет не подпадает под эти правила, то он возвращается на обработку обратно в FORWARD.
Пользовательские цепочки
Эти цепочки подключаются к одной из 3 предопределённых цепочек. Для перехода между цепочками используются правила, в которых в качестве действия указано имя новой цепочки или RETURN. Для добавления цепочек используйте команды +, _new или _insert. Данный список является именованным и не упорядочивается автоматически. Для удаления используйте команду - или _remove.
ВНИМАНИЕ! Механизмы nat, filter, mangle и raw, как и правила маршрутизации, относятся к самой сущности IP-маршрутизатора как целого и работают в тесной связи друг с другом, а также с процедурами IP-маршрутизации и IPsec. Именно по этой причине они настраиваются на уровне системы в целом, а не на уровне интерфейсов по отдельности. (Последнее возможно только для простейших бытовых маршрутизаторов, у которых заранее жёстко определены как роль каждого интерфейса, так и возможные преобразования.)
Чтобы ограничить действие правила одним интерфейсом, необходимо и достаточно указать этот интерфейс в критериях для анализа пакетов.
ПРИМЕЧАНИЕ. Настройку фильтров следует производить в заключительную очередь, предварительно убедившись в нормальной работе всех остальных компонент системы.

Что делать, если это не работает?

  1. Смотреть список фильтров, фактически созданный в соответствии с вашей конфигурацией, и статистику их срабатывания.
  2. Смотреть входящий и исходящий трафик на интерфейсах при помощи утилиты tcpdump. Соответствуют ли их адреса и порты тому, что записано в фильтрах? Обратите внимание на последовательность применения NAT и фильтров (см. схему выше).

Сложные фильтры. Stateful Packet Inspection (SPI).

Правила iptables позволяют учитывать флаги TCP, значения поля ToS/DiffServ и другие поля заголовка пакета. В NSG Linux эти критерии можно указать несколькими способами:

Важный частный случай — это фильтрация пакетов TCP с учётом состояния TCP-соединения (stateful packet inspection, SPI). Состояние соединения, к которому принадлежит пакет, указывается набором флагов в заголовке TCP. Наиболее частая практическая задача — это запретить установление входящих TCP-соединений из внешнего мира в защищаемую сеть. Для установления новых TCP-соединений хост-инициатор посылает пакет с единственным выставленным флагом SYN. Именно такие пакеты следует запретить, не мешая прохождению всех остальных.

Пусть, для определённости, порт eth0 подключён к внутренней сети офиса, имеющей реальные IP-адреса (ситуация крайне редкая на сегодняшний день, но теоретически корректная), порт eth4 — к поставщику услуг Интернет. Следующий фильтр:

ip 
: filter 
: : FORWARD 
: : : 1 
: : : : protocol	= "tcp"
: : : : in-interface	= "eth4"
: : : : extra-options	= "--syn"
: : : : target	= "DROP"

запрещает прохождение пакетов TCP с установленным флагом SYN и не установленными другими флагами, полученных через интерфейс eth4. Таким образом, получается эффект "полупрозрачного зеркала": хосты из внешнего мира не могут устанавливать соединения с хостами во внутренней сети офиса, в то время как для соединений в обратном направлении никаких ограничений не устанавливается. (Аналогичная ситуация имеет место, как побочный эффект, при использовании Source NAT или Masquerading, что является намного более частой задачей.)

ПРИМЕЧАНИЕ. Данный фильтр не запрещает установление TCP-соединений из внешнего мира к самому устройству NSG (в т.ч. Telnet, SSH, HTTP и HTTPS), поскольку такие пакеты маршрутизируются на локальный интерфейс устройства и обрабатываются в цепочке INPUT, а не FORWARD.

Памятка: нужные протоколы и порты.

Если вы придерживаетесь параноидального подхода к безопасности, т.е. "запрещено всё, что не разрешено", то обратите внимание на протоколы и порты, которые следует в таком случае разрешить явным образом. Запрещать их следует только в том случае, если если указанные службы заведомо не используются в вашей сети. Если с протоколом TCP, как правило, всё достаточно понятно и все общеупотребительные номера портов вам известны, то для остальных вам будет полезно заглянуть в нижеприведённый список.

Протоколы 4 уровня (модели OSI)
1   ICMP   Важнейший протокол для отладки сети. В частности, это ping. Запретить его в нормально работающей сети, в принципе, можно. Но проблемы, которые вы при этом сами себе создадите в случае возникновения каких-либо неисправностей, намного больше, чем те сложности, которые вы можете доставить потенциальному злоумышленнику, пытающемуся проникнуть в вашу сеть.
6   TCP   Здесь всё понятно, это основной протокол в большинстве систем. Относительно некоторых нестандартных портов, используемых в оборудовании NSG, см. ниже.
17   UDP   См. список важных портов ниже.
47   GRE   Это не только туннели GRE, но ещё и PPTP (в сочетании с портом TCP 1723 для управляющего соединения). В частности, у многих поставщиков услуг либо не включёна поддержка GRE в фильтрах и NAT, либо не включён NAT HELPER для PPTP (связывающий TCP 1723 и GRE в один поток), и в результате PPTP через них не проходит.
50, 51   ESP, AH   Это протоколы IPsec. Помимо них, могут потребоваться специфические порты UDP для NAT Traversal.
115   L2TP   Протокол L2TP.
Порты UDP
53   Служба DNS — преобразование доменных имён в IP-адреса и обратно.
123   NTP и SNTP — службы сетевого времени.
67, 68   DHCP/BOOTP
69   TFTP
500, 4500   IPsec NAT Traversal
1812, 1813   Наиболее употребительные порты для RADIUS
161, 162   SNMP
10161, 10162   SNMP v3 с защитой данных
137–139   NetBIOS
Нестандартные порты TCP
10050, 10052   Zabbix
50000 и выше   Фирменные механизмы и службы NSG: SMS-handler, event-handler и др. Подробнее см. настройки указанных служб.

© Network Systems Group 2015–2024 Отдел документации