Не работает iptables ubuntu

Обновлено: 02.07.2024

Важно: В последних дистрибутивах RHEL/CentOS по умолчанию используется служба firewallD, уже установленная в системе. Если вы хотите использовать Iptables, сначала нужно ее отключить.

Для рассматриваемого примера используются VPS на Ubuntu 16.04 и локальная машина с SSH-клиентом

Основы Iptables

ACCEPT: разрешить передачу пакета.
DROP: запретить передачу пакета.
RETURN: пропустить текущую цепочку и перейти к следующему правилу в цепочке, которая ее вызвала.

В данном руководстве мы будем работать с одной из таблиц по умолчанию, которая называется фильтром (filter). В таблице фильтра есть три цепочки (набора правил):

INPUT – используется для контроля входящих пакетов. Можно разрешать или блокировать подключения по порту, протоколу или IP-адресу источника.
FORWARD – используется для фильтрации пакетов, приходящих на сервер, но перенаправляемых куда-либо еще.
OUTPUT – используется для фильтрации исходящих пакетов.

Пример настройки iptables

Давайте рассмотрим настройку iptables, на примере настройки доступа к web серверу.

Шаг 1 – Установка брандмауэра Iptables в Linux

1. Установка Iptables

Iptables предустановлен практически во всех дистрибутивах Linux, но если у вас его нет, в системах Ubuntu/Debian воспользуйтесь командами:

или в Centos/RedHat

2. Проверка текущего состояния Iptables

В рассматриваемом примере во всех трёх цепочках установлена политика по умолчанию ACCEPT. Ни в одной цепочке нет никаких правил. Давайте изменим цепочку INPUT для фильтрации входящего трафика.

Шаг 2 – Определение правил

Определение правила означает внесение его в список (цепочку). Вот пример команды Iptables с обычными опциями. Некоторые из них не являются обязательными.

1. Разрешение трафика на локальном узле

Первым делом нам нужно обязательно разрешить трафик через интерфейс loopback. Чтобы связь между приложениями и базами данных на сервере продолжалась в обычном режиме.

Опция -A используется для добавления в цепочку INPUT правила, разрешающего все соединения для интерфейса lo. Это обозначение для интерфейса loopback, он используется для всей связи на локальном узле, например, связи между базой данных и веб-приложением на одной машине.

Теперь все TCP-подключения с этими номерами портов будут разрешены. На самом деле для подключения по порту ssh лучше разрешить не со всех ip адресов, а только с определенных. Для защиты вашего сервера, как это сделать написано ниже

3. Фильтрация пакетов по источнику

Если вам нужно принимать или отклонять пакеты по IP-адресу или диапазону IP-адресов источника, можно указать их при помощи опции -s. Например, чтобы принимать пакеты с адреса 192.168.1.3:

вместо хоста также можно указать и полностью сеть, например для разрешения подключения по ssh только с локальной сети 192.168.1.0/24 пропишите правило

Отклонение команд с IP-адреса задаётся аналогичной командой с опцией DROP:

4. Запрет всего остального трафика

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

Эта команда отклоняет весь трафик, кроме указанных выше портов. Теперь можно проверить свои правила командой:

Как мы видим для интерфейса loopback у нас разрешен любой трафик, по портам 80 и 443 можно подключиться с любого ip. А по порту 22 можно подключиться только с сети 192.168.1.0/24. Не забудьте сохранить настройки, иначе после перезагрузке вы потеряете все изменения. Как сохранить написано ниже.

Удаление правил iptables

Если нужно удалить все правила и прописать все заново с чистого листа, можно воспользоваться командой очистки (flush):

Для удаления правила нужно указать цепочку и номер в списке. В нашем случае это цепочка INPUT и номер 3.

Настройка NAT (MASQUERADE)

Большинство организаций получает от своих интернет-провайдеров ограниченное количество публично доступных IP-адресов, поэтому администратору требуется разделять доступ к Интернету, не выдавая каждому узлу сети публичный IP-адрес. Для доступа к внутренним и внешним сетевым службам узлы локальной сети используют внутренний (частный) IP-адрес. Граничные маршрутизаторы (межсетевые экраны) могут получать входящие соединения из Интернета и передавать их нужным узлам локальной сети и наоборот, направлять исходящие соединения узлов удаленным интернет-службам. Такое перенаправление сетевого трафика может быть опасным, особенно учитывая доступность современных средств взлома, осуществляющих подмену внутренних IP-адресов и таким образом маскирующих машину злоумышленника под узел вашей локальной сети. Чтобы этого не случилось, в Iptables существуют политики маршрутизации и перенаправления, которые можно применять для исключения злонамеренного использования сетевых ресурсов. Политика FORWARD позволяет администратору контролировать маршрутизацию пакетов в локальной сети. Например, чтобы разрешить перенаправление всей локальной сети, можно установить следующие правила (в примере предполагается, что внутренний IP-адрес брандмауэра/шлюза назначен на интерфейсе eth1):

Эти правила предоставляют системам за шлюзом доступ к внутренней сети. Шлюз направляет пакеты от узла локальной сети к узлу назначения и наоборот (опции -o и -i), передавая их через устройство eth1.

Важно: по умолчанию в большинстве дистрибутивов Linux перенаправление отключено. Чтобы его включить, нужно внести изменения в файл конфигурации /etc/sysctl.conf. Найдите там такую строчку net.ipv4.ip_forward = 0 и измените 0 на 1:

Разрешение перенаправления пакетов внутренним интерфейсом брандмауэра позволяет узлам локальной сети связываться друг с другом, но у них не будет доступа в Интернет. Чтобы обеспечить узлам локальной сети с частными IP-адресами возможность связи с внешними публичными сетями, нужно настроить на брандмауэре трансляцию сетевых адресов (NAT). Создадим правило:

В этом правиле используется таблица NAT, поэтому она указывается в явном виде (-t nat) и указана встроенная цепочка этой таблицы POSTROUTING для внешнего сетевого интерфейса eth0 (-o eth0). POSTROUTING позволяет изменять пакеты, когда они выходят из внешнего интерфейса шлюза. Целевое действие -j MASQUERADE заменяет (маскирует) частный IP-адрес узла внешним IP-адресом шлюза. Это называется IP-маскарадингом.

Проброс портов

Сохранение изменений в iptables

Созданные нами правила сохранены в оперативной памяти. Это означает, что при перезагрузке нам нужно будет заново из определить. Чтобы сохранить из после перезагрузки, нужно выполнить следующую команду:

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

Восстановление настроек

Если вы еще не сохраняли настройки, и хотите вернуться к первоначальным настройкам. Используйте iptables-restore.

Заключение

В данном руководстве мы рассмотрели основные моменты работы с Iptables: разрешение трафика только на определенных портах, фильтрацию пакетов по источнику, основы настройки трансляции сетевых адресов (NAT) и сохранение правил после перезагрузки. Однако, важно заметить, что iptables работает только с трафиком ipv4. Если ваш VPS поддерживает ipv6, нужно установить отдельные правила при помощи ip6tables.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

У меня установлены iptables-persistent и netfilter-persistent:

$ dpkg -l '*-persistent' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-============================================-===========================-===========================-============================================================================================== ii iptables-persistent 1.0.4 all boot-time loader for netfilter rules, iptables plugin ii netfilter-persistent 1.0.4 all boot-time loader for netfilter configuration

У меня также есть правила, сохраненные в /etc/iptables/rules.v4 (сейчас я только забочусь о IPv4):

Правило, которое меня действительно интересует, - это один к концу:

-A INPUT -p tcp -m state --state NEW -m multiport --dports 3721:3725 -j ACCEPT

Однако, когда я перезагружаю сервер, я не получаю это правило:

$ sudo iptables -4 -L [sudo] password for kal: Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere REJECT all -- anywhere 127.0.0.0/8 reject-with icmp-port-unreachable ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:https tcp -- anywhere anywhere state NEW multiport dports smtp,submission,urd tcp -- anywhere anywhere state NEW multiport dports pop3,pop3s tcp -- anywhere anywhere state NEW multiport dports imap2,imaps ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh ACCEPT icmp -- anywhere anywhere icmp echo-request LOG all -- anywhere anywhere limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: " DROP all -- anywhere anywhere Chain FORWARD (policy ACCEPT) target prot opt source destination DROP all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere Chain f2b-shadowsocks (1 references) target prot opt source destination RETURN all -- anywhere anywhere Chain f2b-sshd (1 references) target prot opt source destination RETURN all -- anywhere anywhere

Если я посмотрю на вывод журналаctct, netfilter-persistent.service действительно началось успешно:

Если я перезагружу вручную netfilter-persistent.service после полной загрузки машины, я получаю правило, которое я хочу:

$ sudo iptables -4 -L [. ] ACCEPT tcp -- anywhere anywhere state NEW multiport dports 3721:3725 [. ]

Так почему же netfilter-persistent не работает во время загрузки?

Что-то полностью перезаписывает iptables после netfilter-persistent?

Что я могу сделать с этим?

вручную перезапустить У меня также нет ufw или firewalld.

Решено: Iptables - не работают правила (сил уже никаких нет)

Модератор: SLEDopit

Решено: Iptables - не работают правила

Есть eth0 по верх него ppp0, установлен SQUID, настроен как прозрачный, слушает адрес 127.0.0.1:3128.
ip_forwarding 1
Добавляю правило в ip таблицу:
iptables -t nat -A PREROUTING -p tcp -i ppp0 --dport 80 -j DNAT --to-destination 127.0.0.1:1328
или так:
iptables -t nat -A PREROUTING -p tcp -i ppp0 --dport 80 -j REDIRECT --to-port 3128

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

Процитирую с того же руководства табличку:

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

Ну прозрачный прокси в итоге хочу

Ответа там я не нашел. вообщем то это все что есть в рунете. Меня сейчас больше интересует поведение iptables, вот активная таблица для NAT:
*nat
:PREROUTING DROP [0:0]
.
.

Почему входящие пакеты не дропаются? Когда в руководстве сказано:

6.5.3. Действие DROP

Данное действие просто "сбрасывает" пакет и iptables "забывает" о его существовании. "Сброшенные" пакеты прекращают свое движение полностью, т.е. они не передаются в другие таблицы.

И не редиректятся?

6.5.9. Действие REDIRECT

Выполняет перенаправление пакетов и потоков на другой порт той же самой машины.

6.5.2. Действие DNAT

DNAT (Destination Network Address Translation) используется для преобразования адреса места назначения в IP заголовке пакета. Если пакет подпадает под критерий правила, выполняющего DNAT, то этот пакет, и все последующие пакеты из этого же потока, будут подвергнуты преобразованию адреса назначения и переданы на требуемое устройство, хост или сеть.

Вот собственно эти вопросы больше всего интересуют.

Squid Cache: Version 2.6.STABLE17
Debian Lenny/testing с самыми последними обновлениями.

iptables -t nat -A PREROUTING -p tcp -i ppp0 --dport 80 -j REDIRECT --to-port 3128 Писать безграмотно - значит посягать на время людей, к которым мы адресуемся, а потому совершенно недопустимо в правильно организованном обществе. © Щерба Л. В., 1957
при сбоях форума см.блог iptables -t nat -A PREROUTING -p tcp -i ppp0 --dport 80 -j REDIRECT --to-port 3128

Ну да, "Если входящий интерфейс ppp0", но можно его опустить и ничего не изменится.

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

Писать безграмотно - значит посягать на время людей, к которым мы адресуемся, а потому совершенно недопустимо в правильно организованном обществе. © Щерба Л. В., 1957
при сбоях форума см.блог Кроме этого напишите подробнее о сетевых интерфейсах, которые собираетесь использовать.
Например:
eth0 - LAN
eth1 - WAN для PPPoE
ppp0 - соединение с провайдером

eth0 - WAN для PPPoE (Static IP 192.168.0.1)
ppp0 - соединение с провайдером (Dynamic IP)

Вроде все что нужно дал.
Логи сквида чистые. Трафик как-то мимо его ходит Почему на сквид пакеты не заворачивают? Что здесь не так?

iptables -t nat -A PREROUTING -p tcp -i ppp0 --dport 80 -j REDIRECT --to-port 3128

Ну да, "Если входящий интерфейс ppp0", но можно его опустить и ничего не изменится.

А мне почемуто кажется что нужно исходящий. тобиш не -i, а -o. iptables -t nat -A PREROUTING -p tcp -i ppp0 --dport 80 -j REDIRECT --to-port 3128

Ну да, "Если входящий интерфейс ppp0", но можно его опустить и ничего не изменится.

А мне почемуто кажется что нужно исходящий. тобиш не -i, а -o.

i - input interface
o - output interfece

Ну можно вообще его опустить и дать правило типа:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 3128
Только это ничего не поменяет. Да хоть дропать все пакеты приходящие на 80 порт файера, но они не дропаются, а идут дальше по цепочкам Что надо еще сказать iptables'у чтоб цепочки NAT заработали?

попробуйте так ,
iptables -t nat -A PREROUTING -s 192.168.11.0/255.255.255.0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
В зависимости от того какая у вась подсеть на данном интерфейсе.
ip сервера в сквиде я ставил не localhost а ip локальный соответственно 192.168.11.8

Это первое, второе
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE наверное вам нужно это?
У меня без маскарада , не работает обращения к сквиду или это бред?)
Поправьте меня если я неправ.
Только что проверял на работающем сервере в оффисе , при отключении маскарада с включенным форвардом , нет обращений к сквиду из за отсутствия интернета.
При включении маскарада всё бегает нормально и редиректит с 80 на 3128 порт.

Маскарадинг (MASQUERADE) в основе своей представляет то же самое, что и SNAT только не имеет ключа --to-source.

SNAT используется для преобразования сетевых адресов (Source Network Address Translation), т.е. изменение исходящего IP адреса в IP заголовке пакета. Например, это действие можно использовать для предоставления выхода в Интернет другим компьютерам из локальной сети.

Так что это "лишнее". Я один, комп один, прокси и iptables тоже одни

Ну прозрачный прокси в итоге хочу

Как это от куда и куда? Localhost <->SQUID <-> iptables<-> Internet
Дальше локалхоста заворачивать никуда не надо, надо чтобы трафик по 80 порту ходил через локальный прокси, больше ничего ненадо. Прописывать прокси в браузерах не предлагать Ибо хочу разобраться с прозрачным прокси.

Ну прозрачный прокси в итоге хочу

Тогда на досуге можно поизучать:
Таблица 3-3. От локальных процессов

Ну прозрачный прокси в итоге хочу

Тогда на досуге можно поизучать:
Таблица 3-3. От локальных процессов

Изучил вдоль и поперек, но ничего не выходит. Добавляю правило:
-A OUTPUT -d ! 127.0.0.1 -p tcp -m tcp --sport 80 -j REDIRECT --to-ports 3128
Не редиректится. У сквида логи чистые, хотя должна быть вроде по этому правилу запись в access.log. SQUID слушает 127.0.0.1:3128 Почему?
Если делать правило так:
-A OUTPUT -o ppp0 -p tcp -m tcp --sport 80 -j REDIRECT --to-ports 3128
Тогда на SQUID запросы попадают, однако сквид их считает, что запрос пришел из сети ppp0, ну в принципе верно, но у меня в acl deny для всех кроме локалхоста. Как вообще тут быть, непонятно.
В логах сквида появляется:

Не пойму вообще с маршрутизацией. что куда перенаправлять.

Еще непонятно, то что SQUID настроен как прозрачный, а надо ли ему заворачивать исходящие пакеты? Нахрена он тогда прозрачный? Так можно вообще его не делать прозрачным и будет тоже самое. Здесь вообще непонятно про прозрачность.
А вот с этой записью вообще нипонятки:
-A PREROUTING -j DROP
Почему пакеты все равно "гуляют" не смотря на правило?

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

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

Базовые команды iptables

Данный раздел содержит основные команды, с помощью которых можно создать сложный набор правил и управлять интерфейсом iptables в целом.

Запомните: команды iptables нужно запускать с root-привилегиями. Это значит, что нужно выполнить одно из следующих действий:

войти в систему как пользователь root;
использовать su или sudo -i, чтобы развернуть оболочку root;
начинать все команды с sudo (рекомендуемый способ в Ubuntu).

В данном руководстве применяется последний вариант.

Итак, для начала нужно просмотреть список текущих правил iptables. Для этого используется флаг -L:

sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Как можно видеть, список содержит три цепочки по умолчанию (INPUT, OUTPUT и FORWARD), в каждой из которых установлена политика по умолчанию (на данный момент это ACCEPT). Также можно видеть названия столбцов. Но в данном списке нет самих правил, поскольку Ubuntu поставляется без набора правил по умолчанию.

С помощью флага -S данный список можно просмотреть в другом формате, который отражает команды, необходимые для активации правил и политик:

sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Чтобы реплицировать конфигурации, нужно только ввести sudo iptables в начале каждой строки результата. (В зависимости от конфигураций, эта процедура может оказаться немного более сложной при удаленном подключении; если правила, разрешающие текущее соединение, еще не установлены, не стоит устанавливать политику DROP).

Чтобы сбросить текущие правила (если таковые есть), наберите:

sudo iptables -F

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

Прежде чем сбросить правила при удаленном подключении необходимо убедиться, что в цепочках INPUT и OUTPUT установлена политика ACCEPT. Это делается так:

sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -F

Создав правила, разрешающие удаленное подключение, можно установить политику DROP. Итак, перейдем непосредственно к созданию правил.

Создание правил iptables

Оно выглядит так:

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Конечно, сначала оно может показаться невероятно сложным; чтобы понять данное правило, ознакомьтесь с его компонентами:

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

Запросив список правил, можно увидеть изменения:

sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Ознакомившись с базовым синтаксисом, создайте еще несколько правил, принимающих соединение.

Принятие других важных подключений

Ранее iptables получил команду не сбрасывать все текущие соединения, а также принять все соединения, имеющие к ним отношение. Теперь нужно создать правила, принимающие соединения, которые не отвечают вышеперечисленным критериям.

Итак, строки, которые нужно использовать для создания таких правил, выглядят так:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Как видите, они очень похожи на первое правило; возможно, они имеют даже более простую структуру. Новые опции:

То есть, если сервису 1 необходимо установить связь с сервисом 2, прослушивающим соединения на порту 4555, то сервис 1 отправляет пакет на порт 4555 с помощью loopback device. Такое поведение нужно разрешить, поскольку оно является важным условием правильной работы многих программ.

Для этого добавьте следующее правило:

sudo iptables -I INPUT 1 -i lo -j ACCEPT

Оно немного отличается от предыдущих правил; рассмотрите его подробнее:

Чтобы просмотреть текущие правила, используйте флаг -S, поскольку флаг -L не выводит некоторую информацию (например, интерфейс, к которому привязано правило, что очень важно в случае с последним правилом):

sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

Создание правил DROP

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

Если пакет проходит по цепочке INPUT и не отвечает ни одному из четырех правил, будет выполнена политика по умолчанию (ACCEPT), которая так или иначе примет данный пакет. Теперь ее нужно изменить.

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

sudo iptables -P INPUT DROP

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

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

Можно сделать так, чтобы сервер автоматически сбрасывал соединение, если правила удалены. Это сделает сервер более защищенным и труднодоступным. Также это означает, что можно вносить правила в конец цепочки, и при этом все нежелательные пакеты будут сброшены.

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

Чтобы вернуть цепочке INPUT политику ACCEPT, наберите:

sudo iptables -P INPUT ACCEPT

Теперь можно внести в конец данной цепочки правило, которое будет сбрасывать все несоответствующие пакеты:

sudo iptables -A INPUT -j DROP

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

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

Конечно, это также означает, что любое правило, которое необходимо внести в конец цепочки, должно находиться перед правилом сброса. Это можно сделать, либо временно удалив правило сброса:

sudo iptables -D INPUT -j DROP
sudo iptables -A INPUT новое_правило
sudo iptables -A INPUT -j DROP

либо вставив новое правило в конец цепи (но перед правилом сброса), указав номер строки. Чтобы внести правило в строку 4, наберите:

sudo iptables -I INPUT 4 новое_правило

Если правил много, вычислить номер строки вручную достаточно проблематично; в таком случае iptables может пронумеровать строки:

Это позволяет убедиться, что правило было внесено в нужную строку.

Сохранение настроек iptables

По умолчанию все несохраненные правила действуют до следующей перезагрузки сервера; сразу же после перезагрузки несохраненные правила будут потеряны.

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

sudo apt-get update
sudo apt-get install iptables-persistent

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

Так же пакет спросит, нужно ли сохранить существующие правила IPv6 (они устанавливаются при помощи утилиты ip6tables, которая контролирует поступающие пакеты IPv6 почти таким же образом).

По завершении установки появится новый сервис под названием iptables-persistent, который будет запускаться при перезагрузке сервера и возобновлять установленные правила.

Итоги

Читайте также: