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

Отладка iptables и распространенные ошибки брандмауэра?

Это предложил Канонический вопрос о понимании и отладке программного брандмауэра в системах Linux.

В ответ на Ответ EEAA и комментарий @Shog о том, что нам нужны подходящие канонические вопросы и ответы, чтобы закрыть общие относительно простые вопросы об iptables.

Что такое структурированный метод отладки проблем с программным брандмауэром Linux? сетевой фильтр структура фильтрации пакетов, обычно называемая пользовательским интерфейсом iptables?

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

Даже если вы используете такие инструменты, как UFW, БрандмауэрD (он же firewall-cmd), Shorewall или что-то подобное, вам может быть полезно заглянуть под капот без уровня абстракции, который предлагают эти инструменты.

Этот вопрос не является руководством по созданию брандмауэров: проверьте документация по продукту для этого и, например, внести свой вклад в рецепты iptables Поездки и хитрости или выполните поиск по отмеченным вопросы для существующих частый и хорошо оценен результативный Вопросы и ответы.

В основном:

Для просмотра и изменения конфигурации брандмауэра требуются права администратора (root), как и открытие служб в ограниченном диапазоне номеров портов. Это означает, что вы должны либо войти в систему как root или в качестве альтернативы используйте sudo чтобы запустить команду от имени root. Я постараюсь пометить такие команды необязательным [sudo].

Содержание:

  1. Порядок имеет значение или разница между -I и -A
  2. Показать текущую конфигурацию брандмауэра
  3. Интерпретация вывода iptables -L -v -n
  4. Знай свое окружение
  5. Цепи INPUT и FORWARD
  6. Модули ядра

1. Порядок имеет значение или разница между -I и -A

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

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

[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT

а затем обнаружите, что это не подействует.

Причина в том, что -A опция добавляет это новое правило, после всех существующих правил и поскольку очень часто последнее правило в существующем брандмауэре блокирует весь трафик, который явно не разрешен, что приводит к

...
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
8        0  0    ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080

Или эквивалент в iptables-save:

...
iptables -A INPUT  -j REJECT
iptables -A INPUT  -p tcp --dport 8080 -j ACCEPT

и новое правило, открывающее TCP-порт 8080, никогда не будет достигнуто. (О чем свидетельствуют счетчики упорно оставшихся в 0 пакетов и нулевых байт).

Вставив правило с -I новое правило было бы первым в цепочке и будет работать.

2. Показать текущую конфигурацию брандмауэра.

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

Команда [sudo] iptables -L -v -n твой друг (хотя некоторым нравится iptables-save лучше). Часто при обсуждении конфигураций полезно использовать --line-numbers вариант, а также числовые линии. Ссылка на правило №X упрощает их обсуждение.
Примечание: Правила NAT включены в iptables-save вывод, но должны быть указаны отдельно, добавив -t nat вариант т.е. [sudo] iptables -L -v -n -t nat --line-numbers.

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

[root@host ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     784K   65M fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
2    2789K  866M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
3       15  1384 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:443
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain fail2ban-SSH (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       117.239.37.150       0.0.0.0/0           reject-with icmp-port-unreachable
2        4   412 REJECT     all  --  *      *       117.253.208.237      0.0.0.0/0           reject-with icmp-port-unreachable

В качестве альтернативы вывод iptables-save дает сценарий, который может восстановить указанную выше конфигурацию межсетевого экрана:

[root@host ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT

То, что вам будет легче понять, - вопрос предпочтений.

3. Интерпретация вывода iptables -L -v -n

В Политика устанавливает действие по умолчанию, которое цепочка использует, когда не соответствует ни одно явное правило. в INPUT цепочка, настроенная на ПРИНЯТЬ весь трафик.

Первое правило в цепочке INPUT сразу представляет интерес, оно отправляет весь трафик (источник 0.0.0.0/0 и пункт назначения 0.0.0.0/0), предназначенный для TCP-порта 22 (tcp dpt:22) порт по умолчанию для SSH в настраиваемую цель (fail2ban-SSH). Как видно из названия, это правило поддерживается fail2ban (продукт безопасности, который среди прочего сканирует файлы системного журнала на предмет возможных злоупотреблений и блокирует IP-адрес злоумышленника).

Это правило было бы создано командной строкой iptables, аналогичной iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH или находится в выводе iptables-save как -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH. Часто вы можете встретить любое из этих обозначений в документации.

Счетчики показывают, что этому правилу соответствует 784 000 пакетов и 65 мегабайт данных.

Трафик, соответствующий этому первому правилу, затем обрабатывается fail2ban-SSH цепочка, которая, как нестандартная цепочка, перечисляется под цепочкой OUTPUT.

Эта цепочка состоит из двух правил, по одному для каждого нарушителя (исходный IP-адрес 117.253.221.166 или 58.218.211.166), который заблокирован (с reject-with icm-port-unreachable).

 -A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
 -A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable

Пакеты SSH, пришедшие не с этих заблокированных хостов, еще не разрешены и не запрещены, и теперь, когда настраиваемая цепочка завершена, они будут проверяться на соответствие второму правилу в цепочке INPUT.

Все пакеты, не предназначенные для порта 22, прошли первое правило в цепочке INPUT и также будут оцениваться в правиле INPUT №2.

Правило № 2 INPUT делает это межсетевой экран с полным контролем состояния, который отслеживает соединения. Это имеет некоторые преимущества: только пакеты для новых соединений необходимо проверять на соответствие полному набору правил, но после разрешения дополнительные пакеты, принадлежащие установленному или связанному соединению, принимаются без дальнейшей проверки.

Правило ввода № 2 соответствует всем открытым и связанным соединениям, и пакеты, соответствующие этому правилу, не нуждаются в дальнейшей оценке.

Примечание: изменения правил в конфигурации брандмауэра с отслеживанием состояния будут влиять только на новые соединения, но не на установленные.

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

Правило INPUT №3 довольно скучное, весь трафик подключается к кольцевой проверке (lo или 127.0.0.1) интерфейс разрешен.

Правила INPUT 4, 5 и 6 используются для открытия TCP-портов 22, 80 и 443 (порты по умолчанию для соответствующих SSH, HTTP и HTTPS) путем предоставления доступа НОВЫМ соединениям (существующие соединения уже разрешены правилом INPUT 2).

В брандмауэре без сохранения состояния эти правила будут отображаться без атрибутов состояния:

4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

или

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

Последнее правило INPUT, # 7, - это правило, которое блокирует весь трафик, которому НЕ был предоставлен доступ в правилах INPUT 1-7. Довольно распространенное соглашение: запрещается все, что нельзя. Теоретически это правило можно было бы пропустить, установив ПОЛИТИКУ по умолчанию на REJECT.

Всегда исследуйте всю цепочку.

4. Знайте свое окружение

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

4.2. Когда ни одна служба не прослушивает, вы не сможете подключиться и получить ошибка отказа в соединениинезависимо от настроек брандмауэра. Следовательно:

  • Убедитесь, что служба прослушивает (на правильном сетевом интерфейсе / IP-адресе) и использует ожидаемые номера портов с [sudo] netstat -plnut или в качестве альтернативы используйте ss -tnlp.
  • Если ваши службы еще не должны работать, эмулируйте простой слушатель, например, netcat: [sudo] nc -l -p 123 или openssl s_server -accept 1234 [options] если вам нужен прослушиватель TLS / SSL (отметьте man s_server для вариантов).
  • Убедитесь, что вы можете подключиться с самого сервера, т.е. telnet <IP of Server> 123 или echo "Hello" | nc <IP of Server> 123 или при тестировании защищенного сервиса TLS / SSL openssl s_client -connect <IP of Server>:1234, прежде чем попробовать то же самое с удаленного хоста.

4.3. Изучите протоколы, используемые вашими службами. Вы не можете должным образом включать / отключать службы, которых недостаточно понимаете. Например:

  • используется TCP или UDP или оба (как с DNS)?
  • Служба использует фиксированный порт по умолчанию (например, что-то вроде TCP-порта 80 для веб-сервера)?
  • в качестве альтернативы выбирается динамический номер порта, который может варьироваться (например, службы RPC, такие как классический NFS, которые регистрируются с помощью Portmap)?
  • печально известный FTP даже использует два порта, фиксированный и динамический номер порта при настройке на использование пассивного режима ...
  • описание службы, порта и протокола в /etc/services не обязательно совпадать с реальной службой, использующей порт.

4.4. Фильтр пакетов ядра - не единственное, что может ограничивать сетевое подключение:

  • SELinux также может ограничивать сетевые службы. getenforce подтвердит, запущен ли SELinux.
  • Несмотря на то, что TCP Wrappers становятся немного непонятными, они по-прежнему являются мощным инструментом для обеспечения безопасности сети. Проверить с ldd /path/to/service |grep libwrap и /hosts.[allow|deny] контрольные файлы.

5. INPUT или FORWARD Цепи

Более подробно объясняется концепция цепей. Вот но вкратце:

В INPUT chain - это место, где вы открываете и / или закрываете сетевые порты для служб, работающих локально, на хосте, на котором вы выполняете команды iptables.

В FORWARD цепочка - это то место, где вы применяете правила для фильтрации трафика, который перенаправляется ядром в другие системы, фактические системы, а также контейнеры Docker и серверы виртуальных гостевых серверов, когда ваша Linux-машина действует как мост, маршрутизатор, гипервизор и / или выполняет трансляцию сетевых адресов. и экспедирование портов.

Распространенное заблуждение состоит в том, что, поскольку контейнер докеров или гостевой KVM запускается локально, применяемые правила фильтрации должны находиться в цепочке INPUT, но обычно это не так.

6. Модули ядра

Поскольку фильтр пакетов работает в ядре Linux, он также может быть скомпилирован как динамический модуль, фактически несколько модулей. Большинство дистрибутивов включают netfilter в качестве модулей, и необходимые модули netfilter будут загружаться в ядро ​​по мере необходимости, но для некоторых модулей администратору брандмауэра потребуется вручную обеспечить их загрузку. В первую очередь это касается модулей отслеживания соединений, таких как nf_conntrack_ftp который может быть загружен insmod.

Модули, загруженные в настоящее время в работающее ядро, можно отобразить с помощью lsmod.

Метод обеспечения постоянной загрузки модулей при перезагрузке зависит от дистрибутива Linux.

Iptables / Firewall "Введение"

Брандмауэр - это, по сути, сетевой фильтр на основе политик. Брандмауэры Linux построены на Netfilter; структура обработки сетевых пакетов ядра, состоящая из нескольких модулей ядра, выполняющих определенные задачи:

  1. Модуль FILTER (всегда загружается по умолчанию) в основном позволяет нам ПРИНЯТЬ или ОТКЛЮЧИТЬ IP-пакеты на основе определенных критериев соответствия.
  2. Набор модулей NAT позволяет нам выполнять трансляцию сетевых адресов (SNAT, DNAT, MASQUERADE).
  3. Модуль MANGLE позволяет нам изменять определенные поля IP-пакета (TOS, TTL).

Пользователи настраивают структуру Netfilter в соответствии с потребностями своего брандмауэра, используя iptables из командной строки. С помощью iptables мы определяем правила, которые инструктируют ядро, что делать с IP-пакетами, когда они приходят, проходят или покидают нашу систему Linux. Каждый основной процесс Netfilter представлен ТАБЛИЦАМИ (FILTER, NAT, MANGLE) на языке iptables. У них есть несколько конкретных точек перехвата на карте потока сетевых пакетов, где они вызываются ядром для выполнения своих обязанностей. Определенные специально расположенные последовательности вызовов ТАБЛИЦ обычно называются встроенными ЦЕПЬМИ, получая имена PREROUTING, INPUT, FORWARD, OUTPUT и POSTROUTING. Легко запомнить, если мы свяжем ТАБЛИЦУ с «типом процесса», а ЦЕПЬ - с «местом» на карте потока сетевых пакетов, где вызываются экземпляры этих процессов.

Поскольку IP-пакет принимается на сетевом интерфейсе или создается локальным процессом, до тех пор, пока он не будет окончательно доставлен или отброшен, механизм Netfilter будет последовательно проверять и применять правила, содержащиеся в карте потока сетевых пакетов. В каждом блоке, идентифицированном парой TABLE @ CHAIN, пользователь может добавить одно или несколько из этих последовательных правил, содержащих критерии сопоставления IP-пакетов и соответствующий порядок действий. Существуют действия (например, ACCEPT, DROP и т. Д.), Которые могут выполняться более чем одной TABLE, и другие действия (например, SNAT, DNAT и т. Д.), Специфичные для TABLE.

т.е. когда IP-пакет прибывает из сетевого интерфейса, он сначала обрабатывается цепочкой PREROUTING, вызывающей правила, определенные пользователем таблицы MANGLE, если таковые имеются. Если правила, соответствующие текущему пакету, отсутствуют, применяется соответствующий курс действий по умолчанию или «политика» MANGLE @ PREROUTING. На этом этапе, если пакет не был отброшен, процесс продолжит выполнение правил таблицы NAT в цепочке PREROUTING (см. Карту) и так далее. Чтобы упростить компоновку правил, пользователи могут также создавать свои собственные цепочки и «прыгать» в них из разных точек карты по своему желанию.

В то время как встроенные цепочки могут иметь определяемые пользователем политики пакетов ACCEPT или DROP, определенные пользователем цепочки всегда имеют неизменную политику по умолчанию RETURN для вызывающего абонента для продолжения процесса.

Команды iptables

Основные команды iptables заполняют карту потока сетевых пакетов необходимыми правилами обработки.

Общее правило iptables можно записать как:

# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>

Это можно было бы прочитать так:

Netfilter (kernel module) please <Add/Insert/Delete> this rule for <table> at <CHAIN> where packets matching <PKT_MATCHING_CRITERIA> have to be <ACTION>ed

<table>
  -t filter       (the filter table is assumed when omitted)
  -t nat
  -t mangle 

<Add/Insert/Delete>
  -A              (append rule at the end of the chain list)
  -I              (insert rule at the begining of the chain list)
  -D              (Delete rule)

<CHAIN>
  PREROUTING
  INPUT
  FORWARD
  OUTPUT
  POSTROUTING
  USER_DEFINED_CHAIN

<PKT_MATCHING_CRITERIA>
ISO Level-2 matching:
  -i [!] <if_name>    or --in-interface [!] <if_name>
          (OUTPUT and POSTROUTING chains cannot match on input  interfaces)
  -o [!] <if_name>    or --out-interface [!] <if_name>
          (INPUT  and PREROUTING  chains cannot match on output interfaces) 
    -mac-source [!] <xx-xx-xx-xx-xx-xx>
            (OUTPUT and POSTROUTING chains cannot match on input  interfaces)

ISO Level-3 matching:
  -s [!] <src_ip>     or --src [!] <src_ip>   or --source [!] <src_ip>
  -d [!] <dst_ip>     or --src [!] <dst_ip>   or --destination [!] <dst_ip>

ISO Level-4 matching:
  -p [!] <prot_name>    or --protocol [!] <prot_name>  (udp|tcp|icmp)

  Also available when ICMP protocol is defined
  --icmp-type [!] <icmp_type>

  Also available when UDP protocol is defined
  --source-port [!] <udp_src_port>      or --sport [!] <udp_src_port>
  --destination-port [!] <udp_dst_port> or --dport [!] <udp_dst_port>

  Also available when TCP protocol is defined
  --source-port [!] <tcp_src_port>      or --sport [!] <tcp_src_port>
  --destination-port [!] <tcp_dst_port> or --dport [!] <tcp_dst_port>
  --tcp-flags [!] <tcp_flags>   (SYN|ACK|FIN|RST|URG|PSH|ALL|NONE)
    --syn
  --tcp-option [!] <tcp_option#>

  --state [!] <state>
  -m <match> [options]

    note: [!] = negation operator

<ACTION>                (also called TARGET)
  -j ACCEPT             (process continues with rules of the next table in map)
  -j DROP               (discard current packet)
  -j REJECT             (discard current packet with ICMP notification)
      option:
      --reject-with <reject_type>
  -j USER_DEFINED_CHAIN   (start traversing USER_DEFINED_CHAIN rules)
  -j RETURN               (return from USER_DEFINED_CHAIN)
  -j LOG                  (log to syslog, then process next rule in table)
      options:
      --log-level <level>
      --log-prefix <prefix>
      --log-tcp-sequence
      --log-tcp-options
      --log-ip-options
      --log-uid

nat table specific
  -j SNAT             (rewrite the source IP address of the packet)
      option:
      --to <ip_address>
  -j SAME             (idem SNAT; used when more than one source address)
      options:
      --nodst 
      --to <a1-a2>
  -j MASQUERADE       (idem SNAT; used when the replace IP is dynamic)
  -j DNAT             (rewrite the destination IP address of the packet)
      option:
      --to <ip_address>
  -j REDIRECT         (rewrite dst IP to 127.0.0.1, PREROUTING and OUTPUT only)
      option:
      –-to-port <port#>

mangle table specific
  -j ROUTE            (explicitly route packets, valid at PREROUTING)
      options:
      --iface <iface_name>
      --ifindex <iface_idx>
  -j MARK             (set Netfilter mark values)
      options:
      --set-mark <value>
      --and-mark <value>
      --or-mark <value> 
  -j TOS              (set the IP header Type of Service field) 
      option:
      --set-tos <value>
  -j DSCP             (set the IP header Differentiated Services Field)
      options:
      --set-dscp <value>
      --set-dscp-class <class>
  -j TTL              (set the IP header Time To Live field)
      options:
      --ttl-set <value>
      --ttl-dec <value>
      --ttl-inc <value>

Вспомогательные команды iptables завершают настройку сценария по умолчанию, правила листинга, правила очистки и т. Д.

#iptables -t <table> -L             
       (Lists the <table> rules in all chains)
#iptables -t <table> -L <CHAIN>     
       (Lists the <table> rules in <CHAIN>)

#iptables -t <table> -N <CHAIN>     
       (Creates a user-defined <CHAIN> for holding <table> rules)
#iptables -t <table> -E <CHAIN> <NEWCHAIN>  
       (Renames <CHAIN> that holds <table> rules to <NEWCHAIN>)

#iptables -t <table> -X   
       (Deletes all user-defined chains created for holding <table> rules)
#iptables -t <table> -X <CHAIN>
       (Deletes user-defined <CHAIN> created for holding <table> rules)

#iptables -t <table> -P <CHAIN> <ACTION>     where <ACTION> = ACCEPT|DROP
       (Sets the default policy of <table> rules at <CHAIN> to <ACTION>)

#iptables -t <table> -F             
       (Flushes (deletes) all <table> rules in all chains)
#iptables -t <table> -F <CHAIN>
       (Flushes (deletes) all <table> rules in <CHAIN>)

#iptables -t <table> -R <CHAIN> <INDEX> <NEWRULE>
       (Replaces <table> rule at position <INDEX> in <CHAIN> with <NEWRULE>

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

#iptables-save > fileName
      (Save the currently active Netfilter ruleset to fileName)

#iptables-restore < fileName
      (Restore Netfilter ruleset to the one saved in fileName)

Итоги Iptables

Netfilter - чрезвычайно гибкий и мощный фреймворк, но за это нужно платить; Iptables сложен. С точки зрения пользователя, некоторые термины, такие как TABLE, CHAIN, TARGET, не очень хорошо соответствуют концепции, которую они представляют, и поначалу не имеют особого смысла. Тема длинная, у команд вроде бесконечный список параметров. Что еще хуже, нет ни одной книги, которая бы действительно освоила Iptables. В основном они делятся на две категории: «книга рецептов» или «справочная книга». Я думаю, что это введение дает вам моментальный снимок ландшафта Netfilter / Iptables, а также необходимую дозу предварительно обработанного материала man-страницы. Если вы новичок в iptables, прочитав эти параграфы несколько раз, вы будете готовы прочитать примеры iptables. Немного попрактиковавшись, вы скоро начнете писать свои собственные правила.

Межсетевые экраны

Брандмауэр в основном предназначен для динамического разрешения или запрета сетевого трафика на основе набора правил. На этом этапе легко понять, почему среда Linux Netfilter / Iptables идеально подходит для построения межсетевых экранов. Глядя на карту потока сетевых пакетов, мы обнаруживаем два особенно интересных места в таблице FILTER в цепочках INPUT и FORWARD; Мы можем выбрать IP-адрес источника, IP-протокол (UDP / TCP), порт назначения (80, 21, 443 и т. Д.) И т. Д., Если мы ПРИНИМАЕМ, ОТКЛОНЯЕМ или просто ОТКЛЮЧАЕМ конкретный IP-пакет. Именно это брандмауэр делает в 80% случаев, когда защищает веб-сервер от неавторизованных сетевых запросов. Остальные 20% времени манипулируют сетевыми пакетами (NAT, MANGLE).

Сценарии межсетевых экранов

Существуют сотни различных компоновок межсетевого экрана, отвечающих различным потребностям, но 3 из них можно считать наиболее типичными сценариями межсетевого экрана.

  1. Простой веб-сервер с одним или несколькими интерфейсами, подключенными к Интернету. Политика включает в себя основные правила для разрешения ограниченного входящего доступа, неограниченного исходящего доступа и правила защиты от спуфинга. Переадресация IP отключена.
  2. Этот брандмауэр подключается к Интернету и к защищенной внутренней области. Политика включает в себя основные правила для разрешения ограниченного входящего доступа, неограниченного исходящего доступа и правила защиты от спуфинга. Поскольку защищенная область использует частные IP-адреса, необходим NAT источника. Переадресация IP включена.
  3. Этот брандмауэр подключается к Интернету, внутренней защищенной и демилитаризованной зоне. Политика включает в себя основные правила, разрешающие ограниченный входящий доступ, неограниченный исходящий доступ и правила защиты от спуфинга. Поскольку защищенные зоны и зоны DMZ используют частные IP-адреса, им требуется NAT источника и назначения. Переадресация IP включена.

Я написал это для: http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html

Общие проблемы с разными протоколами

DNS: DNS использует порт 53 UDP по умолчанию, но сообщения, которые не помещаются в одну дейтаграмму UDP, будут передаваться вместо этого с использованием TCP (обычно зональные передачи и т. Д.), Требуя открытия порта 53 TCP, когда вы запускаете сервер имен.

Эл. адрес: Многие потребительские интернет-провайдеры блокируют SMTP-трафик (или, по крайней мере, порт TCP 25 по умолчанию), что делает невозможным прямой прием или отправку электронной почты, а их клиенты вынуждены использовать SMTP-ретранслятор провайдера для всей исходящей электронной почты, а иногда и для входящей электронной почты. Относится к §1.1.

FTP: FTP - необычный протокол в том смысле, что два используются соединения. Первое - это управляющее соединение, по умолчанию FTP-сервер будет прослушивать TCP-порт 21 для этого. Управляющее соединение используется для аутентификации и выдачи команд. Фактическая передача файлов и такие вещи, как вывод списка каталогов, переходят второе TCP-соединение, DATA-соединение. В активном FTP это соединение DATA будет инициировано с FTP-сервера через TCP-порт 20 и подключаться к FTP-клиенту. Активный FTP не очень хорошо работает с пользователями, находящимися за межсетевыми экранами и шлюзами NAT, поэтому по большей части он вышел из употребления. Большинство FTP-серверов вместо этого поддерживают пассивный FTP. При пассивном FTP сервер FTP открывает прослушиватель соединения DATA на втором порту, к которому затем может подключиться клиент FTP. Проблема брандмауэра в том, что порт DATA может быть любым доступным непривилегированным портом в диапазоне 1024-65536.

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

iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT

В брандмауэре с отслеживанием состояния вам не нужно явно открывать порт DATA, вспомогательный модуль netfilter распознает динамический порт, который назначается, и динамически откроет этот порт для правильного клиента, пометив соединение DATA как RELATED после чего он будет соответствовать общему правилу:

  iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT

Для этого требуется правильная модуль ядра загружается, в случае FTP вручную путем запуска, например insmod nf_conntrack_ftp, делая эту постоянную зависимость при перезагрузке, зависит от дистрибутива.

Примечание: Модуль отслеживания FTP-соединения завершится ошибкой, если FTP используется с SSL, поскольку управляющее соединение будет зашифровано, и nf_conntrack_ftp больше не сможет читать PASV-ответ.

NFS и подобные Услуги RPC: Проблема со службами RPC заключается в том, что они изначально не используют конкретный фиксированный порт. Они могут выбрать любой доступный порт наугад, который затем будет зарегистрирован с помощью демона RPC Portmap. Клиент, пытающийся подключиться, запросит демон Portmap, а затем подключится напрямую к правильному порту. Это решило проблему нехватки зарезервированных портов ...

С точки зрения брандмауэра необходимо открыть порт 111 TCP / UDP и фактический порт, который служба RPC использует в настоящее время. Проблема открытия такого случайного порта в брандмауэре обычно решается путем ограничения службы RPC, такой как сервер NFS, на использование заранее определенного фиксированного порта.