Sfera-perm.ru

Сфера Пермь
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Iptables просмотр счетчика правил

iptables: пишем в лог все заблокированные соединения/пакеты

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

Описание

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

Открываем его любым текстовым редактором, например, nano и вносим туда следующие строчки:

Сохраняем изменения в файле. Первая строчка говорит rsyslog, что нужно искать в логе фразу «IPTables-Dropped: «, и когда он её находит, то переносит в файл /var/log/iptables.log
Вторая строчка просто дает понять rsyslog, чтобы найденные строки, подходящие под условия, не дублировались в основной лог /var/log/messages.
Перезапускаем rsyslog:

Все, подготовительный этап, позволяющий писать лог iptables в отдельный файл мы сделали. Можно его не делать и тогда все записи будут появляться в /var/log/messages, но ИМХО это не очень удобно.

Переходим ко второму этапу, непосредственной настройке iptables.

Возможны три варианта настройки:

Вариант 1 — Записываем в лог (логируем) только входящие отброшенные соединения/пакеты:

Разберем что же означает каждая из команд в примере выше:
iptables -N LOGGING: Создаем новую цепочку LOGGING
iptables -A INPUT -j LOGGING: Все входящие пакеты (для которых не сработало ни одно из ваших собственных правил и которые из-за политики DROP все-равно должны заблокироваться) попадают в цепочку LOGGING
iptables -A LOGGING -m limit —limit 2/min -j LOG —log-prefix «IPTables-Dropped: » —log-level 4: Логируем все входящие пакеты в syslog (/var/log/messages).
iptables -A LOGGING -j DROP: Отбрасываем все пакеты, которые пришли в цепочку LOGGING.

Вариант 2 — Записываем в лог только исходящие отброшенные соединения/пакеты:
Все тоже самое, что и в примере выше, за исключением цепочки, теперь используем OUTPUT вместо INPUT.

Вариант 3 — Записываем в лог все исходящие и входящие отброшенные соединения/пакеты:

Была ли эта статья Вам полезна?

Комментарии к статье (16)

    • Константин
    • 29.06.2020 21:42

    Спасибо! Очень помогло, хорошая статья!

    В последнем примере после iptables -A LOGGING -j DROP намертво завешивается хост

    У вас к хосту физический доступ или через ssh? Если физический, то это явно какие то проблемы. Если доступ через ssh, то, видимо, у вас нет правил, явно разрешающих доступ по ssh, поэтому после ввода указанной команды — вас и блокирует. Чтобы команды из этой статьи нормально работали, необходимо, чтобы политика по умолчанию у iptables была установлена на DROP, т.е. блокировались любые соединения, для которых не указаны явные правила (поэтому, не забываем заранее написать правила для ssh, чтобы можно было потом попасть на хост). В статье речь идет о том, чтобы все соединения/пакеты для которых нету правил и которые будут все-равно заблокированы, сначала писались в лог-файл, а уже потом блокировались. Раз уже не первый комментарий по этой теме, то допишу сейчас статью, чтобы читатели меньше путались.

    Ну ты и умник. У меня специально прописано правило, разрешающее соединение по SSH. Но один хрен у меня соединение обрезается после последней волшебной команды. Ладно еще хоть сервак под рукой.

    Статью надо читать дальше заголовка и головой думать, когда команды вводишь, тогда и проблем будет гораздо меньше.

    Статью читал вдумчиво и несколько раз. После ввода правила дропа — все соединения обрубаются несмотря на разрешающее правило по порту 22. Тебе как еще это донести? Вроде русским языком уже написано, а по китайски я не умею.

    В статье жирным красным и желтым цветом выделено, что данный вариант подходит
    1) Только для конфигураций, где политика по-умолчанию установлена на Drop
    2) Что данные команды надо прописывать в самый низ конфига, после всех остальных правил (например, разрешающих соединение по ssh).
    Если не соблюдать очередность (например, просто ввести команды в консоли не в том порядке, а не внести в конфиг) — то до разрешающих правил просто не дойдет очередь (т.к. предложенные команды логирования — отбрасывают все пакеты, после записи в лог, как оно и должно происходить, при политике Drop), а если соблюдать, то там уже лишнего нечего блокировать, т.к. из-за политики Drop, все, что дошло до правил логирования (они ведь в самом низу, после всех других), предложенных в статье, итак должно быть отброшено.

    Мне кажется, что ты не понимаешь о чем пишешь. Вот мой кусок iptables-save:
    :INPUT DROP [1060:84267]
    :FORWARD DROP [0:0]
    :OUTPUT ACCEPT [727:191642]
    :LOGGING — [0:0]
    -A INPUT -j LOG —log-prefix «Iptables INPUT » —log-level 7
    -A INPUT -s 192.168.163.0/24 -i enp1s0 -p tcp -m tcp —dport 22 -j ACCEPT
    -A INPUT -s 192.168.163.0/24 -i enp1s0 -p icmp -j ACCEPT
    -A INPUT -m state —state RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -i lo -j ACCEPT
    -A INPUT -s 192.168.163.0/24 -p tcp -m multiport —ports 3128 -j ACCEPT
    -A INPUT -s 192.168.163.0/24 -p tcp -m multiport —ports 3129 -j ACCEPT
    -A INPUT -j LOGGING
    -A FORWARD -j LOG —log-prefix «Iptables FORWARD » —log-level 7
    -A FORWARD -m conntrack —ctstate RELATED,ESTABLISHED -j ACCEPT
    -A FORWARD -p icmp -j ACCEPT
    -A FORWARD -s 192.168.0.0/24 -p tcp -m multiport —ports 53 -j ACCEPT
    -A FORWARD -s 192.168.0.0/24 -p udp -m multiport —ports 53 -j ACCEPT
    -A OUTPUT -j LOGGING
    -A LOGGING -m limit —limit 2/min -j LOG —log-prefix «IPTables-Dropped: »
    COMMIT

    Политика по умолчанию INPUT — DROP. Разрешающее правило для подключения к ссш порту есть и оно выше. И как только я ввожу ту волшебную команду «iptables -A LOGGING -j DROP» — все, консоль обрубается. Что я делаю не так?
    Да, выше уже есть логирование инпут и форвард, я просто для твоего примера убирать не стал, т.к. оно влиять не должно.

    Я конечно далеко не эксперт по iptables, но:

    Политика для цепочки OUTPUT установлена в ACCEPT, хотя и в статье, и в комментариях я писал, что описанные в статье действия применимы ТОЛЬКО для политики DROP.

    И как только я ввожу ту волшебную команду «iptables -A LOGGING -j DROP» — все, консоль обрубается

    Ну так что ему сказано, то он и делает, все пакеты из цепочки OUTPUT он отправляет в LOGGING. Из-за вот этого правила:

    А после ввода «волшебной команды»:

    Все пакеты в цепочке LOGGING (а в приведенном конфиге в нем оказываются пакеты из цепочек INPUT и OUTPUT) пишутся в лог и блокируются.

    Т.е. Все исходящие соединения с сервера включая ssh отправляем в цепочку LOGGING и блокируем. Поэтому доступ и пропадает.
    Вот этого правила » -A OUTPUT -j LOGGING » не должно вообще быть с такими настройками политик, иначе все исходящие соединения будут писаться в лог и блокироваться, в том числе обрубая доступ по ssh.

    Только разрещающие правила OUTPUT и INPUT смешаются в параллели LOGGING и правила разрешающие писать надо типа:
    iptables -A LOGGING -s -i -p -dport -j ACCEPT

    То есть вот такой код примерно:

    Имейте ввиду, что и FORWARD и INPUT и OUTPUT чейны попадут в слитый LOGGING, поэтому это точно не best practice

    Вообще то когда я писал предыдущий ответ, у меня были подозрения насчет OUTPUT:ACCEPT. Но к этому времени я уже достаточно много провозился с этим iptables. А когда я наткнулся на эту статью, у меня ветер в голове гулял и я нихрена не знал. Поэтому большинство комментов подобно моим — ничего не работает, афтар дятел. Так что может стоит твой последний коммент с разбором в саму статью поместить, чтобы поменьше ошибок было.
    А лучше задать для примера общий рабочий набор правил:
    iptables -P INPUT -j DROP
    iptables -P OUTPUT -j DROP
    iptables — P FORWARD -j DROP
    и далее как в статье:
    iptables -N LOGGING
    iptables -A INPUT -j LOGGING
    iptables -A OUTPUT -j LOGGING
    iptables -A LOGGING -m limit —limit 2/min -j LOG —log-prefix «IPTables-Dropped: » —log-level 4
    iptables -A LOGGING -j DROP

    ага, мат_удален какая-то, логируем все входящие, а потом дропаем все входящие и получаем логирование дропуных входящих, шутка юмора

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

    Не вздумайте выполнять эти команды. Заблокируете себе и всем остальным доступ к сайту

    MNorin.com

    Блог про Linux, Bash и другие информационные технологии

    Настройка iptables от простого к сложному. Часть 1.

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

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

    Сценарии сетевых подключений

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

    1) Все пользователи могут просматривать сайт. По умолчанию сайт на русском языке.
    2) Если пользователи пришли с адресов , то им должен быть показан сайт на украинском. В нашем примере это будет, допустим, интернет-магазин с одним доменным именем, отображаемый на русском или украинском языке, и имеющий в продаже свой набор для России и Украины. У нас будет просто два сайта, один на русском, второй на украинском, и по адресу, с которого пришел клиент, будет определяться, на какой сайт он попадет. Пример взят из головы, на практике, конечно, такие вопросы решаются по другому. Можно также не разрешать просмотр сайта с китайских адресов из-за постоянного спама в комментариях на китайском.
    3) Из офиса должна быть доступна почта, из других мест она не должна быть доступна.
    4) Извне должна быть обеспечена возможность подключения к ВПН
    5) Мы можем использовать только несколько DNS-серверов, которым мы доверяем. Все остальные сервера DNS должны быть недоступны
    6) …..

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

    Настройка iptables: Самая простая конфигурация

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

    В первую очередь, необходимо очистить загруженные правила:

    INPUT, OUTPUT, FORWARD — это три основные цепочки, по которым будут идти пакеты, входящие, исходящие и проходящие с интерфейса на интерфейс.

    После этого необходимо задать политику по умолчанию. Их всего две — ACCEPT и DROP, принимать пакеты или не принимать. Для боевого сервера всегда необходимо выбирать DROP, а затем открывать всё, что необходимо и не более того.

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

    И после этого уже можно приступать к изменению политик по умолчанию:

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

    Итак. В данный момент у нас открыт только порт SSH-сервера для входящих соединений, на все остальные порты соединения проходить не будут. Теперь надо добавить прием соединений на порты остальных сервисов, если они на вашем сервере запущены.

    DNS (обычно достаточно разрешить UDP, но можно также добавить и TCP):

    И так далее. Порты, которые необходимо открыть для того или иного сервиса, и протокол можно посмотреть в файле /etc/services, в котором перечислены все закрепленные за определенными сервисами порты.

    Но это еще не всё. Порты открыты, сервисы доступны извне, но почта не работает и доменные имена не резолвятся. Дело в том, что при запросе DNS-серверов запрос отправляется с произвольного свободного порта из числа непривелегированных, точно так же, как и соединение с другим почтовым сервером. И ответ эти сервисы отправляют на тот же самый порт. А этот порт, как вы понимаете, у нас закрыт. Мы могли бы открыть этот порт, но мы не знаем, с какого порта будет исходящее соединение. Поэтому мы можем сделать самое простое, что может быть,- разрешить соединения с определенных портов удаленного компьютера:

    Эти два правила разрешают входящие соединения с портов 25/tcp и 53/udp, поэтому, когда с этих портов приходят пакеты по соответствующему протоколу, они будут приняты. Если вы планируете обновлять систему, программное обеспечение или устанавливать пакеты, необходимые для работы, то вам придется разрешить соединения с 80 порта удаленных машин.

    Вот теперь самая простая конфигурация iptables у нас готова.

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

    Обработка источника соединения

    Идем дальше. соединение по определенным портам нам необходимо не со всем Интернетом, а с определенными машинами, с определенными IP-адресами. Поэтому мы можем немного усложнить правила, добавив в них адрес источника пакетов.

    Данное правило позволяет принимать пакеты на 22 порт по протоколу TCP только из источника с адресом 123.123.123.123, на это указывает параметр «-s» (source, источник). Таким образом вы можете ограничить соединения с сервером по SSH одним определенным IP-адресом, либо определенной подсетью, если укажете маску подсети, из которой разрешены соединения вместо отдельного IP-адреса.

    Если у вас всегда используется один и тот же почтовый шлюз, через который ваш сервер отправляет почту, то вы можете, например, ограничить соединения с порта 25/tcp, указав этот шлюз в качестве источника.

    Правила для конкретного сетевого интерфейса или IP-адреса

    На сервере может быть несколько сетевых интерфейсов. Обычно их как минимум два — внешний сетевой и так называемый loopback-интерфейс 127.0.0.1, доступ к которому извне невозможен, если отсутствует соответствующее перенаправление пакетов. У вас также может как минимум еще один IP-адрес, используемый совместно с алиасом сетевого интерфейса, или еще один физический сетевой интерфейс. И на каждом IP-адресе или сетевом интерфейсе могут работать определенные сервисы. Например, на одном веб-сервер Apache, а на втором сервер службы доменных имен bind9. И когда вы разрешаете соединения на определенный порт без указания этого сетевого интерфейса, вы открываете доступ к этому порту на всех интерфейсах. Поэтому есть два способа сузить область действия разрешения.

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

    Этот пример показывает, как можно использовать адрес назначения в правиле iptables. При этом также можно использовать адрес источника:

    В данном пример мы уже ограничиваем доступ двумя адресами, что позволяет получить доступ по SSH к серверу по адресу 234.234.234.234 с адреса 123.123.123.123, с остальных адресов доступ вы получить не сможете.

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

    Такой вариант разрешает доступ по SSH на сетевом интерфейсе eth0, на остальных сетевых интерфейсах доступ по SSH будет отсутствовать.

    Всё, что мы только что рассмотрели — это только самое начало, в следующей части будет продолжение…

    Iptables

    iptables — утилита командной строки, является стандартным интерфейсом управления работой межсетевого экрана (брандмауэра) netfilter для ядер Linux, начиная с версии 2.4. Для использования утилиты iptables требуются привилегии суперпользователя (root).

    Содержание

    • 1 История
    • 2 Архитектура
      • 2.1 Основные понятия
    • 3 Примечания
    • 4 Литература
    • 5 Ссылки

    История [ править | править код ]

    Изначально разработка netfilter и iptables шла совместно, поэтому в ранней истории этих проектов есть много общего. Подробности см. в статье про netfilter.

    Предшественниками iptables были проекты ipchains (применялась для администрирования фаервола ядра Linux версии 2.2) и ipfwadm (аналогично для ядер Linux версий 2.0). Последний был основан на BSD-утилите ipfw.

    iptables сохраняет идеологию, ведущую начало от ipfwadm: функционирование фаервола определяется набором правил, каждое из которых состоит из условия и действия, применяемого к пакетам, подпадающим под это условие. В ipchains появилась концепция цепочек — независимых списков правил. Были введены отдельные цепочки для фильтрации входящих (INPUT), исходящих (OUTPUT) и транзитных (FORWARD) пакетов. В продолжении этой идеи, в iptables появились таблицы — независимые группы цепочек. Каждая таблица решала свою задачу — цепочки таблицы filter отвечали за фильтрацию, цепочки таблицы nat — за преобразование сетевых адресов (NAT), к задачам таблицы mangle относились прочие модификации заголовков пакетов (например, изменение TTL или TOS). Кроме того, была слегка изменена логика работы цепочек: в ipchains все входящие пакеты, включая транзитные, проходили цепочку INPUT. В iptables через INPUT проходят только пакеты, адресованные самому хосту.

    Такое разделение функциональности позволило iptables при обработке отдельных пакетов использовать информацию о соединениях в целом (ранее это было возможно только для NAT). В этом iptables значительно превосходит ipchains, так iptables может отслеживать состояние соединения и перенаправлять, изменять или отфильтровывать пакеты, основываясь не только на данных из их заголовков (источник, получатель) или содержимом пакетов, но и на основании данных о соединении. Такая возможность фаервола называется stateful-фильтрацией, в отличие от реализованной в ipchains примитивной stateless-фильтрации (подробнее о видах фильтрации см. статью о фаерволах). Можно сказать, что iptables анализирует не только передаваемые данные, но и контекст их передачи, в отличие от ipchains, и поэтому может принимать более обоснованные решения о судьбе каждого конкретного пакета. Более подробно о stateful-фильтрации в netfilter/iptables см. Netfilter#Механизм определения состояний.

    В будущем, разработчики netfilter планируют заменить iptables на nftables — инструмент нового поколения, пока находящийся в ранней стадии разработки [2] .

    Архитектура [ править | править код ]

    Основные понятия [ править | править код ]

    Ключевыми понятиями iptables являются:

    • Правило — состоит из условия, действия и счетчика. Если пакет соответствует условию, к нему применяется действие, и он учитывается счетчиком. Условия может и не быть — тогда неявно предполагается условие «все пакеты». Указывать действие тоже не обязательно — в отсутствие действия правило будет работать только как счетчик.
      • Условие — логическое выражение, анализирующее свойства пакета и/или соединения и определяющее, попадает ли данный конкретный пакет под действие условия текущего правила.
      • Действие — описание действия, которое нужно проделать с пакетом (и/или соединением), если пакет (и/или соединение) попадает под условие этого правила. О действиях более подробно будет рассказано ниже.
      • Счетчик — компонент правила, обеспечивающий учёт количества пакетов, которые попали под условие данного правила. Также счетчик учитывает суммарный объём таких пакетов в байтах.
    • Цепочка — упорядоченная последовательность правил. Цепочки можно разделить на пользовательские и базовые.
      • Базовая цепочка — цепочка, создаваемая по умолчанию при инициализации таблицы. Каждый пакет, в зависимости от того, предназначен ли он самому хосту, сгенерирован им или является транзитным, должен пройти положенный ему набор базовых цепочек различных таблиц. Кроме того, базовая цепочка отличается от пользовательской наличием «действия по умолчанию» (default policy). Это действие применяется к тем пакетам, которые не были обработаны другими правилами этой цепочки и вызванных из неё цепочек. Имена базовых цепочек всегда записываются в верхнем регистре (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING).
      • Пользовательская цепочка — цепочка, созданная пользователем. Может использоваться только в пределах своей таблицы. Рекомендуется не использовать для таких цепочек имена в верхнем регистре, чтобы избежать путаницы с базовыми цепочками и встроенными действиями.
    • Таблица — совокупность базовых и пользовательских цепочек, объединённых общим функциональным назначением. Имена таблиц (как и модулей условий) записываются в нижнем регистре, так как в принципе не могут конфликтовать с именами пользовательских цепочек. При вызове команды iptables таблица указывается в формате -t имя_таблицы. При отсутствии явного указания, используется таблица filter.

    nftables

    Nftables — подсистема Linux, отвечающая за обработку сетевых пакетов, фреймов и датаграмм. В RHEL 8 будет использоваться для работы по умолчанию, а значит самое время посмотреть на неё чуть более внимательно.

    Администраторы, и пользователи интересующиеся, об nftables скорее всего ранее слышали уже не раз. Проект был анонсирован в 2008, затем была предварительная версия, чуть позже прослойка совместимости с iptables, и вот в начале 2014, nftables был включен в основную ветку ядра 3.13.

    Так как с RHEL дистрибутивами и их производными я работаю чуть плотнее, чем с deb семейством, смотреть на nftables будем в Fedora. Там есть и nft, и транслятор правил, и свежее ядро — всё что нужно, что бы посмотреть на подсистему в работе. В принципе, для CentOS 8 в будущем, данная заметка так же будет актуальна, так как и dnf туда тоже пришёл.

    Установка nftables.

    Пока что, его нет по умолчанию в дистрибутиве, так что поставим. Вместе с этим, поставим и утилиту, которая позволит нам транслировать правила iptables в nftables:

    И запускаем в работу:

    Немного теории.

    Совсем немного. Своеобразный конспект. Описывая правила для обработки пакетов мы можем управлять:

    • Таблицами. Они определяют семейство протоколов, с которым ведётся работа. Каждая таблица может обозначить только одно семейство (есть допущение для inet, об этом чуть дальше). Т. е. мы не можем в рамках одной таблицы работать с ip, и arp, например. Для понимания — при работе с ip4 мы так же использовали iptables, а для arp — arptables отдельно. Предусмотрено пять семейств, которые можно использовать в таблицах — ip, ip6, inet (объединяет ip и ip6), arp, bridge.
    • Цепочками. Они состоят из правил, в рамках которых обрабатываются пакеты. Доступно три типа цепочек — filter (для фильтрации), route (для роутинга) и nat (для ната соответственно). Здесь могут быть использованы хуки — prerouting, input, forward, output, postrouting.
    • Правилами. Непосредственно то, с помощью чего мы описываем как будут обрабатываться пакеты.
    • Инструкциями (Statements). Определяют что будет сделано с пакетом, который попал под определённое условие или правило. Здесь доступны accept, drop, reject, queue, return, jump, goto, continue.
    Работа с nftables.

    Рассмотрим базовый пример с открытием и закрытием порта с помощью nftables. Допустим, у нас есть сервис, который работает на 80 порте. Мы сперва ограничим доступ к нему, а затем откроем его вновь.

    1. Для начала, создадим таблицу:

    Проверим что она появилась у нас:

    2. Теперь добавим цепочку:

    И посмотрим что изменилось:

    3. Добавим правило, которым ограничим доступ к 80 порту:

    Опять посмотрим на изменения:

    4. Логично предположить, что для открытия порта нам нужно выполнить:

    Но получить доступ к 80 порту после этого нам не удастся, и если мы заглянем в список правил, будет понятно почему:

    Нам нужно удалить правило с drop, для этого мы обращаем внимание на отметку handle 2 в выводе, и с её помощью удаляем запрещающее правило:

    Проверяем текущее состояние:

    И без проблем получаем доступ к 80 порту нашего сервера.

    5. Если мы хотим полной очистки, то выполняем:

    После чего, вывод «nft -a list ruleset» будет пустым.

    Транлсяция правил из iptables.

    Для того, что бы быстро перевести имеющееся iptables правило в nft формат, можно воспользоваться утилитой iptables-translate. Работает она очень просто:

    Т. е. мы просто вводим правило, и получаем его аналог, который можем использовать в nftables.

    Nftables и firewalld.

    Отдельно не могу не отметить вот какой момент — пользователи, привыкшие работать с firewalld могут продолжать работать с ним, и писать правила с его помощью. Начиная с версии 0.6, firewalld может использовать в качестве бекенда nftables вместо iptables. Так что не смотря на всю критичность перемен в RHEL 8, у нас остаётся уже знакомый нам инструмент, который переход на nftables как минимум облегчит.

    По примерам конкретных правил для nft мы пройдём отдельно, в будущих заметках.

    голоса
    Рейтинг статьи
    Читайте так же:
    Счетчик реального времени овен
Ссылка на основную публикацию
Adblock
detector