Linux

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

  • 23.12.2014
  • 28 587
  • 19
  • 04.12.2019
  • 20
  • 20
  • 0
iptables: пишем в лог все заблокированные соединения/пакеты

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

Информация в данной статье написана для случая, когда политика по-умолчанию для цепочек INPUT и OUTPUT установлена на DROP. Т.е. любые соединения, для которых не указаны разрешающие правила - будут блокироваться фаерволом. Команды, которые приведены ниже, просто позволяют прежде чем заблокировать такое соединение/пакет, сначала записать информацию о нем в лог-файл, а уже потом заблокировать. Если же у вас политика по-умолчанию установлена на ACCEPT, то описанные ниже команды вам не подойдут, т.к. введя их, вы просто заблокируете доступ себе и другим.

Описание

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

touch /etc/rsyslog.d/10-iptables.conf

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

:msg, contains, "IPTables-Dropped: " -/var/log/iptables.log
& ~

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

service rsyslog restart

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

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

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

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

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

iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

Разберем что же означает каждая из команд в примере выше:
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.

iptables -N 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

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

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
Была ли эта статья Вам полезна?

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

    • Макс

    Решение, то что надо. Все работает четко. Спасиб.

    • Константин

    Спасибо :).

    • Евгений

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

    • Александр

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

      • AJIekceu4

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

        • Марат

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

          • AJIekceu4

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

            • Марат

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

              • AJIekceu4

              В статье жирным красным и желтым цветом выделено, что данный вариант подходит
              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" - все, консоль обрубается. Что я делаю не так?
              Да, выше уже есть логирование инпут и форвард, я просто для твоего примера убирать не стал, т.к. оно влиять не должно.

                • AJIekceu4

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

                :OUTPUT ACCEPT

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

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

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

                -A OUTPUT -j LOGGING

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

                iptables -A LOGGING -j DROP

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

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

                  • Димон

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

                  • Димон

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

                  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 -p tcp --dport 22 -j LOG --log-prefix "IPTables Accepted: SSH detected: "
iptables -A LOGGING -p tcp --dport 22 -j ACCEPT
### дальше дроп не нужен, ибо дефолтовая политика DROP, но лог нужен
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables Dropped: " --log-level 4

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

                • Andrei

                Марат, у тебя нет правил ESTABLISHED,RELATED ACCEPT, поэтому и ломается соединение. Почитай про это

              • Марат

              Вообще то когда я писал предыдущий ответ, у меня были подозрения насчет 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

    • Сергей

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

      • AJIekceu4

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

    • Ваня

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Напоминаем Вам, что Ваше сообщение будет опубликовано только после проверки администратором сайта. Обычно это занимает 1-2 рабочих дня.