@ Карта сайта News Автора!

Bog BOS: netfilter и iptables/arptables: фильтрация пакетов в Linux: принципы работы, установка и настройка

Последние изменения:
2024.11.22: sysadmin: systemd-journald (централизованное хранение)
2024.11.11: sysadmin: Linux: пространства имён
2024.11.06: sysadmin: настройка TCP/IP в Linux: виртуальный интерфейс и виртуальный мост
2024.10.25: sysadmin: Linux VFS, атрибуты, расширенные атрибуты, ACL

Последнее изменение файла: 2019.10.16
Скопировано с www.bog.pp.ru: 2024.11.23

Bog BOS: netfilter и iptables/arptables: фильтрация пакетов в Linux: принципы работы, установка и настройка

netfilter (встроенные в ядро Linux 2.4/2.6 средства фильтрации пакетов) и программы (iptables, iptables-save, iptables-restore) управления ими могут быть использованы для организации сетевого экрана (firewall), NAT (Network Address Translation; NPT - Network Port Translation; DNAT - Destination Network Address Translation; SNAT - Source Network Address Translation) или усиления защиты сервера. В отличие от ipchains умеет отслеживать соединения (stateful packet filtering), при этом пакеты обязательно дефрагментируются; цепочки правил объединяются в таблицы различного назначения (filter, nat, mangle), используются специальные модули для различных протоколов (в т.ч. прикладного уровня). Также позволяет менять заголовки пакетов и помечать пакеты для дальнейшего использования при маршрутизации и управлении трафиком (iproute2, tc). В основном, работает на межсетевом уровне TCP/IP, но захватывает транспортный уровень (TCP, UDP) и уровень доступа к сети (MAC адреса). Одновременное использование данных из 2 пакетов по-прежнему невозможно, для настоящей фильтрации на прикладном уровне пользуйтесь прокси серверами. Для управления фильтрацией пакетов протокола ARP используется утилита arptables (пакет arptables_jf).

В статье описываются:

Предварительные условия

Для работы netfilter необходимо иметь ядро 2.3.15 или более новое, при генерации которого включены CONFIG_NETFILTER, CONFIG_IP_NF_IPTABLES, CONFIG_IP_NF_FILTER (таблица filter), CONFIG_IP_NF_NAT (таблица nat), CONFIG_BRIDGE_NETFILTER, а также многочисленные дополнительные модули: CONFIG_IP_NF_CONNTRACK (отслеживание соединений), CONFIG_IP_NF_FTP (вспомогательный модуль для отслеживания FTP соединений), CONFIG_IP_NF_MATCH_* (дополнительные типы шаблонов соответствия пакетов: LIMIT, MAC, MARK, MULTIPORT, TOS, TCPMSS, STATE, UNCLEAN, OWNER), CONFIG_IP_NF_TARGET_* (дополнительные действия в правилах: REJECT, MASQUERADE, REDIRECT, LOG, TCPMSS), CONFIG_IP_NF_COMPAT_IPCHAINS для совместимости с ipchains, CONFIG_BRIDGE_NF_EBTABLES и CONFIG_BRIDGE_EBT_* для работы в режиме моста, прочие CONFIG_IP_NF_* и CONFIG_IP6_NF_*. Полезно также указать CONFIG_PACKET.

Наличие netfilter в ядре определяется по файлам /proc/net/ip_tables_names (список используемых таблиц), /proc/net/ip_tables_targets (2.6) и /proc/net/ip_tables_matches (2.6).

Управление осуществляется с помощью утилиты iptables.

Функциональность netfilter может расширяться с помощью модулей ядра. Головной модуль ядра называется iptable_filter, модуль поддержки утилиты iptables называется ip_tables, вспомогательные модули обычно имеют префикс "ipt_" (ipt_state, ipt_REJECT, ipt_LOG; хотя - ip_conntrack/nf_conntrack). Большинство модулей загружается автомагически, но некоторые всё же приходиться загружать вручную (ip_conntrack_ftp - иначе может не работать в режиме Active; ip_conntrack_irc - иначе может не работать отсылка файлов по DCC; ip_nat_ftp; ip_nat_irc; ip_conntrack_tftp/nf_conntrack_tftp на клиенте - иначе не будет работать TFTP).

Управление дополнительными модулями ядра осуществляется с помощью разделяемых библиотек (см. /lib/iptables/) для утилиты iptables.

netfilter позволяет эмулировать ipfwadm и ipchains с помощью модулей ядра (с некоторых пор перестали включаться в стандартное ядро), при этом модуль ip_tables необходимо выгрузить.

Таблицы, цепочки, путь пакета

Каждый проверяемый IP-пакет проходит по цепочке ("сквозь строй") правил, определяющих, что с ним делать. Правило состоит из шаблона, которому должен соответствовать пакет, и действия. Каждая цепочка имеет действие по умолчанию (политику). В отличие от ipchains правила входной цепочки (INPUT) применяются после принятия решения о том, что это "наш" пакет и маршрутизировать его не надо; правила выходной цепочки (OUTPUT) применяются не только к исходящим наружу пакетам, но и к передаваемым на локальный интерфейс. Правила цепочки FORWARD применяются только к транзитным пакетам. Имеется возможность добавлять к набору свои цепочки. netfiler обрабатывает несколько наборов (таблиц) цепочек:

Приблизительная схема обработки пакетов (взята из NAG2; по-моему, ради красоты картинки художник пожертвовал истиной: пропал маршрут из второй точки маршрутизации на localhost, он не проходит через FORWARD):

В таблицах nat и mangle имеются цепочки PREROUTING и POSTROUTING. Правила цепочки PREROUTING применяется к пакетам сразу после получения пакета на входе интерфейса перед выбором маршрута, а правила цепочки POSTROUTING непосредственно перед выводом пакета через интерфейс. В таблице nat нет цепочек INPUT и FORWARD.

Реальная последовательность обработки входящего пакета, предназначенного для локального процесса такова:

  1. просматривается цепочка PREROUTING таблицы mangle (используется для преобразования пакетов), здесь же происходит отслеживание соединений
  2. просматривается цепочка PREROUTING таблицы nat (используется для DNAT, фильтровать здесь не стоит)
  3. маршрутизация: если пакет надо маршрутизовать вовне, то переходим к обработке проходящего пакета
  4. просматривается цепочка INPUT таблицы mangle
  5. просматривается цепочка INPUT таблицы filter

Реальная последовательность обработки пакета, уходящего с нашего хоста такова:

  1. маршрутизация: определение исходящего адреса, адреса назначения, используемого интерфейса; если пакет маршрутизируется внутрь, то переходим к предыдущей процедуре (п. 1 или 4?)
  2. просматривается цепочка OUTPUT таблицы mangle, фильтровать здесь не стоит, здесь же происходит отслеживание локально создаваемых соединений
  3. просматривается цепочка OUTPUT таблицы nat (NAT для локально сгенерированных пакетов)
  4. повторная маршрутизация, т.к. в таблицах mangle и nat пакет мог быть изменён; если пакет маршрутизируется внутрь, то переходим к предыдущей процедуре (п. 1 или 4?)
  5. просматривается цепочка OUTPUT таблицы filter
  6. просматривается цепочка POSTROUTING таблицы mangle
  7. просматривается цепочка POSTROUTING таблицы nat (используется для SNAT, фильтровать здесь не стоит)

Реальная последовательность обработки проходящего пакета (от п.3 первой процедуры):

  1. просматривается цепочка FORWARD таблицы mangle
  2. просматривается цепочка FORWARD таблицы filter
  3. повторная маршрутизация, т.к. в таблице mangle пакет мог быть изменён; если пакет маршрутизируется внутрь, то переходим к первой процедуре (п. 1 или 4?)
  4. просматривается цепочка POSTROUTING таблицы mangle
  5. просматривается цепочка POSTROUTING таблицы nat (используется для SNAT и Masquerading, фильтровать здесь не стоит)

Текст и иллюстрации документации netfilter имеют множество разночтений, оставляя свободу воли (то ли пакетов, то ли разработчиков ;). Автор iptables-tutorial рекомендует использовать тестовый набор правил, записывающий в журнал имя каждой пройденной пакетом цепочки и таблицы.

Отслеживание соединений

netfilter отслеживает соединения с помощью модуля ip_conntrack (имеет параметр hashsize, задающий размер хеша) и протоколозависимых модулей (icmp, tcp, ftp, tftp, irc, amanda, sctp) при обработке цепочки PREROUTING таблицы nat (для локально сгенерированных пакетов при обработке цепочки OUTPUT) и хранит их в специальной таблице. При этом все пакеты обязательно дефрагментируется. Соединения удаляются из таблицы по истечению интервала ожидания при отсутствии очередного пакета. При выгрузке модуля (см. IPTABLES_MODULES_UNLOAD в /etc/sysconfig/iptables-config) таблица соединений очищается. Рассматриваемый пакет может находиться с точки зрения настройки (у ядра своя таблица состояний) в одном из 4 состояний относительно ранее отслеженных соединений:

Пакет в состоянии NEW с точки зрения conntrack может быть продолжением реального соединения (т.е. не иметь бита SYN), например, в результате изменения цепочек, загрузки модуля и т.д.. В любом случае, при "отлове" подозрительных соединений необходимо предусмотреть сброс попыток соединений, в которых мошенниками подставлен наш адрес:

-A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
-A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Максимально возможное число отслеживаемых соединений задаётся в файле /proc/sys/net/ipv4/ip_conntrack_max (/proc/sys/net/nf_conntrack_max) (каждое соединение занимает 350 байт невытесняемой памяти). Набор заплаток tcp-window-tracking для ядра 2.4 (входит в ядро 2.6) обеспечивает возможность задать значения по умолчанию для интервалов ожидания при удалении записи о соединении из таблицы для различных ситуаций в /proc/sys/net/ipv4/netfilter/ip_conntrack_*_timeout* (/proc/sys/net/netfilter/ip_conntrack_*_timeout*) (в секундах). Мне пришлось (давно было) записать 600 в ip_conntrack_tcp_timeout_close[_wait] по всей цепочке, иначе завершение соединения блокировалось (FIN/ACK от клиента или RST от сервера), часть завершающих пакетов всё равно "режется" (клиент закрывает полузакрытый сокет только когда ему требуется следующее соединения, а запись о соединении из таблицы conntrack уже удалена, а увеличивать ip_conntrack_tcp_timeout_close до суток не хочется). Также позволяет "порулить" поведением машины состояний через переменные (/proc/sys/net/ipv4/netfilter/):

Таблицу текущих соединений можно посмотреть в файле /proc/net/ip_conntrack (/proc/net/nf_conntrack)

Управление цепочками

Управление цепочками производится с помощью программы iptables. После загрузки определены цепочки (все с политикой ACCEPT) INPUT, FORWARD и OUTPUT в таблице filter; PREROUTING, POSTROUTING и OUTPUT в таблице nat; PREROUTING, INPUT, FORWARD, OUTPUT и POSTROUTING в таблице mangle. Удалить их нельзя. Формат команды:

iptables [-t имя-таблицы] команда [шаблон] [-j действие]

Команды:

Действия (target)

Действия (действие в недопустимом месте эквивалентно DROP), при завершении просмотра текущей цепочки, производится просмотр следующих по порядку таблиц:

Шаблоны

Шаблон правила может включать (если в качестве адреса хоста указывается имя, соответствующее нескольким адресам, то добавляется соответствующее количество правил; восклицательный знак инвертирует шаблон; несколько подшаблонов действуют как "И"):

Параметры модуля расширения tcp

Параметры модуля расширения udp

Параметры модуля расширения icmp

Параметры модуля расширения mac

Параметры модуля расширения mark

Параметры модуля расширения limit (защита от DoS атак или ограничение записей в журнал; используется модель дырявого ведра: задаётся объём ведра и скорость его самоопустошения, шаблону соответствуют пакеты, помещающиеся в ведро):

Параметры модуля расширения iprange (задание интервалов IP-адресов)

Параметры модуля расширения multiport (список портов, до 15 портов)

Параметры модуля расширения length (длина пакета)

Параметры модуля расширения owner (только в цепочке OUTPUT, не всегда срабатывает)

Параметры модуля расширения pkttype

Параметры модуля расширения recent (динамическая генерация правил по событию; ведётся несколько именованных списков событий, для каждого события записывается время, исходящий адрес, исходящий порт, число пакетов, TTL)

Параметры модуля расширения state (состояние соединения согласно conntrack):

Параметры модуля расширения conntrack (расширение возможностей модуля state):

Параметры модуля расширения helper (протоколозависимый модуль отслеживания соединений):

Параметры модуля расширения tos (также имеются модуля dscp, ecn)

Параметры модуля расширения tcpmss (Maximum Segment Size in TCP, только для пакетов с SYN или SYN/ACK)

Параметры модуля расширения ttl

Модуль расширения unclean не имеет параметров. Позволяет отлавливать "неправильные" пакеты.

Параметры модуля расширения ah (IPSec, необходимо также указать номер протокола 51)

Параметры модуля расширения esp (IPSec, необходимо также указать номер протокола 50)

Утилиты iptables-save и iptables-restore

Тщательно составленные и отлаженные цепочки необходимо сохранять с помощью утилиты iptables-save, выводит на stdout, параметры:

Вывод утилиты имеет простой текстовый формат, допускающий редактирование. Комментарии начинаются с символа '#'. Таблицы выводятся по очереди, перед каждой таблицей в отдельной строке выводится имя таблицы после символа '*', затем перечисляются имеющиеся в таблице цепочки, каждое имя цепочки выводится в отдельной строке после символа ':', после имени выводится политика цепочки и счётчики, затем выводятся все правила таблицы, каждое правило выводится отдельной строкой, в конце таблицы выводится ключевое слово "COMMIT". Правила выводятся в формате утилиты iptables, только не указывается имя таблицы.

Сохранённые ранее цепочки можно загрузить в ядро с помощью утилиты iptables-restore (читает с stdin, по умолчанию восстанавливаемые таблицы сбрасываются, параметры):

Сервис в Red Hat Linux

В дистрибутивах Red Hat Linux имеется сервис iptables (управляемый обычными chkconfig и service) в /etc/rc.d/init.d с функциями:

Примеры и советы

При настройке правил на удалённом хосте рекомендуется оставлять себе пути отступления, например, перед внесением изменений добавить в crontab строку, возвращающую настройки обратно, если что-то пойдёт не так (/sbin/service iptables stop).

Часто используемые правила должны быть в начале цепочки. Для дальнейшей оптимизации цепочка разбивается на подцепочки (например, по типу протокола).

Пример настройки рабочей станции или небольшого внутреннего сервера:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:icmp_packets - [0:0]
# ICMP (other types covered by RELATED)
-A icmp_packets -p icmp --icmp-type 8 -j ACCEPT
-A icmp_packets -p icmp --icmp-type 11 -j ACCEPT
# replies
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#
-A INPUT -p icmp -j icmp_packets
-A INPUT -i lo -j ACCEPT
# CUPS server
#-A INPUT -i eth0 -p udp -m udp --dport 631 -j ACCEPT
# SSH server
-A INPUT -i eth0 -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
# to prevent mass logging
-A INPUT -i eth0 -p udp -d широковещательный-адрес --sport 137:139 --dport 137:139 -j DROP
-A INPUT -i eth0 -p udp -d 255.255.255.255 --dport 445 -j DROP
-A INPUT -j LOG
#
-A OUTPUT -p ALL -s 127.0.0.1 -j ACCEPT
-A OUTPUT -p ALL -s свой-адрес -j ACCEPT
-A OUTPUT -j LOG
COMMIT

Пример настройки маршрутизатора между отделами (eth0 - DMZ)

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:icmp_packets - [0:0]
#
# output anything
#
-A OUTPUT -p ALL -s 127.0.0.1 -j ACCEPT
-A OUTPUT -p ALL -s 192.168.0.6 -j ACCEPT
-A OUTPUT -p ALL -s 192.168.1.6 -j ACCEPT
-A OUTPUT -p ALL -s 192.168.2.6 -j ACCEPT
...
-A OUTPUT -j LOG
#
# ICMP (other types covered by RELATED)
#
-A icmp_packets -p icmp --icmp-type 8 -j ACCEPT
-A icmp_packets -p icmp --icmp-type 11 -j ACCEPT
#
# input
#
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j icmp_packets
-A INPUT -i lo -j ACCEPT
# SSH
-A INPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT
# to prevent mass logging
-A INPUT -p udp -d 192.168.1.255 --sport 137:139 --dport 137:139 -j DROP
...
-A INPUT -p udp -d 255.255.255.255 --dport 445 -j DROP
-A INPUT -p udp -d 255.255.255.255 --sport 68 --dport 67 -j DROP
-A INPUT -j LOG
#
# forward
#
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -p icmp -j icmp_packets
-A FORWARD -i lo -j ACCEPT
# SSH выборочно
-A FORWARD -i ethX -p tcp -s откуда --dport 22 -d куда -j ACCEPT
...
# общий syslog
-A FORWARD -i ethX -p udp --dport 514 -d адрес-сервера -j ACCEPT
...
# главный NTP сервер и сервера отделов
-A FORWARD -i ethX -p udp -s NTP-сервер-отдела -d главный-NTP-сервер --dport 123 -j ACCEPT
...
# нормальный DNS не для всех отделов
-A FORWARD -i eth1 -p udp -m udp -d внешний-DNS-сервер --dport 53 -j ACCEPT
-A FORWARD -i eth2 -p udp -m udp --dport 53 -j DROP
...
# SMTP
-A FORWARD -i eth0 -p tcp -d SMTP-сервер-отдела --dport 25 -j ACCEPT
-A FORWARD -i eth1 -p tcp -d внешний-SMTP-сервер --dport 25 -j ACCEPT
...
# LMTP/POP/IMAP
-A FORWARD -i eth0 -p tcp -d IMAP-сервер --dport 24 -j ACCEPT
-A FORWARD -i eth1 -m multiport -p tcp -d IMAP-сервер --dport 110,143,993,995 -j ACCEPT
...
# этот отдел имеет почти полноценный доступ в интернет
-A FORWARD -i eth1 -o eth0 -p tcp -j ACCEPT
# а этот только через прокси
-A FORWARD -i eth2 -p tcp -d прокси-сервер --dport 3128 -j ACCEPT
# доступ к webdav серверу с удалённой точки (HTTPS, т.к. внешний канал)
-A FORWARD -i eth5 -s внешняя-сеть -p tcp -d сервер --dport 443 -j ACCEPT
# to prevent mass logging
-A FORWARD -i eth1 -p udp -d 192.168.1.255 --sport 137:139 --dport 137:139 -j DROP
-A FORWARD -i eth1 -p udp -d 255.255.255.255 --dport 445 -j DROP
-A FORWARD -i eth1 -p udp -d 255.255.255.255 --sport 68 --dport 67 -j DROP
-A FORWARD -i eth1 -p udp -d 255.255.255.255 --sport 67 --dport 68 -j DROP
...
-A FORWARD -m state --state NEW -j LOG --log-prefix "NEW "
-A FORWARD -m state --state INVALID -j LOG --log-prefix "INVALID "
-A FORWARD -m state --state ESTABLISHED -j LOG --log-prefix "ESTABLISHED "
-A FORWARD -m state --state RELATED -j LOG --log-prefix "RELATED "
COMMIT
*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# доступ к webdav серверу с удалённой точки (HTTPS, т.к. внешний канал)
-A PREROUTING -i eth5 -p tcp -s внешняя-сеть -d 192.168.5.6 --dport 443 -j DNAT --to-destination сервер:443

Пример настройки входного маршрутизатора (eth0 - DMZ, eth1 и eth2 - внешние каналы)

*filter
:FORWARD DROP [0:0]
:INPUT DROP [0:0]
:OUTPUT DROP [0:0]
:icmp_packets - [0:0]
#
# output anything
#
-A OUTPUT -p ALL -s 127.0.0.1 -j ACCEPT
-A OUTPUT -p ALL -s 192.168.0.2 -j ACCEPT
-A OUTPUT -p ALL -s внешний-адрес-1 -j ACCEPT
-A OUTPUT -p ALL -s внешний-адрес-2 -j ACCEPT
-A OUTPUT -j LOG
#
# ICMP (other types covered by RELATED)
#
-A icmp_packets -p icmp --icmp-type 8 -j ACCEPT
-A icmp_packets -p icmp --icmp-type 11 -j ACCEPT
#
#
# input
#
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j icmp_packets
-A INPUT -i lo -j ACCEPT
# SSH изнутри
-A INPUT -i eth0 -m state --state NEW -p tcp --dport 22 -j ACCEPT
# SSH из головной организации
-A INPUT -m state --state NEW -p tcp -s адрес --dport 22 -j ACCEPT
# our DNS
-A INPUT -p udp -i eth0 -d 192.168.0.2 --dport 53 -j ACCEPT
-A INPUT -p tcp -i eth0 -d 192.168.0.2 --dport 53 -j ACCEPT
-A INPUT -p udp -i eth1 -d внешний-адрес-1 --dport 53 -j ACCEPT
-A INPUT -p tcp -i eth1 -d внешний-адрес-1 --dport 53 -j ACCEPT
...
# smtp
-A INPUT -p tcp -i eth0 -d 192.168.0.2 --dport 25 -j ACCEPT
-A INPUT -p tcp -i eth1 -d внешний-адрес-1 --dport 25 -j ACCEPT
-A INPUT -p tcp -i eth2 -d внешний-адрес-2 --dport 25 -j ACCEPT
# to prevent mass logging
-A INPUT -p tcp -i eth2 --dport 445 -j DROP
-A INPUT -j LOG
#
# forward
#
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -p icmp -j icmp_packets
# www сервер в DMZ, но виден снаружи как внешний-адрес-1
-A FORWARD -i eth0 -p tcp -d адрес-сервера --dport 80 -j ACCEPT
-A FORWARD -i eth1 -p tcp -d адрес-сервера --dport 80 -j ACCEPT
# выход прокси сервера наружу
-A FORWARD -i eth0 -s адрес-прокси -m state --state NEW -j ACCEPT
# to prevent mass logging
-A FORWARD -i eth1 -p tcp -d внешний-адрес-1 --dport 445 -j DROP
-A FORWARD -j LOG
COMMIT
#
*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
#
*nat
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
# доступ к www серверу изнутри (через прокси)
-A PREROUTING -i eth0 -p tcp -d внешний-адрес-1 --dport 80 -j DNAT --to-destination адрес-сервера:80
# доступ к www серверу снаружи
-A PREROUTING -i eth1 -p tcp -d внешний-адрес-1 --dport 80 -j DNAT --to-destination адрес-сервера:80
# адрес преобразуется, чтобы пакет вернулся тем же маршрутом
-A POSTROUTING -s прокси-сервер -p tcp -d адрес-сервера --dport 80 -j SNAT --to-source 192.168.0.2
# NAT
-A POSTROUTING -o eth1 -j SNAT --to-source внешний-адрес-1
...

Фильтрация пакетов протокола ARP

Управление цепочками производится с помощью программы arptables (пакет arptables_jf или arptables). После загрузки определены цепочки (все с политикой ACCEPT) IN, FORWARD и OUT в таблице filter (модуль arptable_filter). Удалить их нельзя. Формат команды:

arptables [-t имя-таблицы] команда [шаблон] [-j действие]

Команды:

Действия (действие в недопустимом месте эквивалентно DROP), при завершении просмотра текущей цепочки, производится просмотр следующих по порядку таблиц:

Шаблон правила может включать (если в качестве адреса хоста указывается имя, соответствующее нескольким адресам, то добавляется соответствующее количество правил; восклицательный знак инвертирует шаблон; несколько подшаблонов действуют как "И"):

Имеется модуль mangle, который позволяет изменить IP и MAC адреса отправителя и получателя. Действия: DROP, CONTINUE и ACCEPT.

Тщательно составленные и отлаженные цепочки необходимо сохранять с помощью утилиты arptables-save, выводит на stdout, параметры (отсутствуют в новом пакете arptables)):

Вывод утилиты имеет простой текстовый формат, допускающий редактирование. Комментарии начинаются с символа '#'. Таблицы выводятся по очереди, перед каждой таблицей в отдельной строке выводится имя таблицы после символа '*', затем перечисляются имеющиеся в таблице цепочки, каждое имя цепочки выводится в отдельной строке после символа ':', после имени выводится политика цепочки и счётчики, затем выводятся все правила таблицы, каждое правило выводится отдельной строкой, в конце таблицы выводится ключевое слово "COMMIT" (отсутствуют в новом пакете arptables). Правила выводятся в формате утилиты arptables, только не указывается имя таблицы. В новом пакете arptables имена таблиц фиксированы: INPUT, OUTPUT, FORWARD.

Сохранённые ранее цепочки можно загрузить в ядро с помощью утилиты arptables-restore (читает с stdin, по умолчанию восстанавливаемые таблицы сбрасываются, параметры (отсутствуют в новом пакете arptables):

В дистрибутивах Red Hat Linux имеется сервис arptables_jf (управляемый обычными chkconfig и service) в /etc/rc.d/init.d с функциями:

Например, для "полной развязки" интерфейсов необходимо задать следующие правила:

*filter
:IN DROP [0:0]
-A IN -d адрес-на-eth0 -i eth0 -j ACCEPT
-A IN -d адрес-на-eth1 -i eth1 -j ACCEPT
:OUT DROP [0:0]
-A OUT --source-mac адрес-eth0 -s адрес-на-eth0 -o eth0 -j ACCEPT
-A OUT --source-mac адрес-eth1 -s адрес-на-eth1 -o eth1 -j ACCEPT
:FORWARD DROP [0:0]
COMMIT

Ссылки

@ Карта сайта News Автора!

Bog BOS: netfilter и iptables/arptables: фильтрация пакетов в Linux: принципы работы, установка и настройка

Последние изменения:
2024.11.22: sysadmin: systemd-journald (централизованное хранение)
2024.11.11: sysadmin: Linux: пространства имён
2024.11.06: sysadmin: настройка TCP/IP в Linux: виртуальный интерфейс и виртуальный мост
2024.10.25: sysadmin: Linux VFS, атрибуты, расширенные атрибуты, ACL



Copyright © 1996-2024 Sergey E. Bogomolov; www.bog.pp.ru