dmesg залил логи брандмауэра

8

В моем iptables у меня есть правило, которое регистрирует отброшенные пакеты:

-A INPUT -i eth0       -j   LOG  --log-prefix "FW: " --log-level 7
-A INPUT -i eth0       -j   DROP

И у /etc/rsyslog.confменя есть другое правило, которое отправляет эти журналы в выделенный файл /var/log/firewall.log.

:msg, contains, "FW: "                    -/var/log/firewall.log
& ~

& ~Немедленно удаляет журналы, так что они не флудить syslogили другие файлы журналов.

Это работает хорошо, за исключением того, что оно заполняется dmesgэтими журналами брандмауэра ( /var/log/dmesgно не выводом команды dmesg).

Есть ли способ предотвратить отображение этих журналов в dmesg?

logs iptables rsyslog

— Мартин Вегтер
источник

Какой смысл все регистрировать?

— 0xC0000022L

1

Это действительно не очень хорошая идея, чтобы регистрировать все отброшенные пакеты. Лучше, чем устранить симптомы, было бы более конкретно с вашим правилом регистрации. Например, не очень разумно регистрировать любые пакеты, которые не связаны с каким-либо соединением и не делают ничего особенного (например, инициализация соединения). Было бы намного лучше сократить это до таких важных вещей, как «Хост A хотел подключиться к порту B». Потенциально количество причин, по которым пакет отброшен, значительно больше, чем число причин, по которым вы отбросили бы его по соответствующей причине.

— Андреас Визе

1

@Andreas Wiese - я упростил свое правило ради этого вопроса. Мои правила более сложные и конкретные. Но в любом случае, вопрос заключается в том, как предотвратить dmesgзатопление, а не в правилах брандмауэра.

— Мартин Вегтер

Смотрите также этот ответ о демоне ведения журнала Netfilter ulogd2. Вот как я решил проблему.

— mivk

4

Вы можете использовать NFLOGцель вместо LOG:

NFLOG
    This target provides logging of matching packets. When this  target  is  set  for  a
    rule, the Linux kernel will pass the packet to the loaded logging backend to log the
    packet. This is usually used in combination with nfnetlink_log as  logging  backend,
    which  will multicast the packet through a netlink socket to the specified multicast
    group. One or more userspace processes may subscribe to the  group  to  receive  the
    packets.  Like  LOG, this is a non-terminating target, i.e. rule traversal continues
    at the next rule.

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

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

-A INPUT -i eth0 -m limit --limit 10/minutes -j LOG --log-prefix "FW: " --log-level 7
-A INPUT -i eth0 -j DROP

Это будет в среднем 10 пакетов в минуту. Конечно, вы можете настроить это в соответствии с вашими потребностями.

— Андреас Визе
источник

Я не смог найти какую-либо информацию, как настроить rsyslogдля регистрации NFLOGпакетов. Мне нужно решение, которое будет работать с rsyslog.

— Мартин Вегтер

2

@MartinVegter - NFLOG будет работать с rsyslog. Для NFLOG вы должны использовать ulogd (я думаю, что нужен ulogd2) в качестве посредника. Он будет прослушивать сокет netlink, чтобы получить журналы и доставить их (как настроено) в системный журнал. Если ulogd2 недоступен, используйте ulogd (1.x) и цель ULOG.

— Кристофер Кашелл

0

Это может быть связано с уровнем журнала, который вы используете в iptables. Как я понимаю из уровней журнала документации rsyslog: «Приоритет принадлежит одному из следующих ключевых слов в порядке возрастания: отладка, информация, уведомление, предупреждение, предупреждение (то же самое, что и предупреждение), ошибка, ошибка (такая же, как ошибка), крит, бдительность, эмерг, паника (так же, как эрм). " Как насчет попытки указать уровень журнала в iptables, используя его имя, то есть «уведомление». Хорошо служит мне право для публикации без проверки, так как я теперь думаю, что это не проблема вообще. Я реализовал схему, аналогичную описанной выше, и у меня возникла та же проблема. У меня ядро centos 7 v3.10.0 и, очевидно, начиная с v3.5, похоже, что ведение журнала ядра выполняется с использованием / dev / kmsg, и я предполагаю, что dmesg каким-то образом получит свой вклад оттуда.

— VaughanR
источник

0

Когда вы установили уровень журнала на 7 с помощью команды:

-A INPUT -i eth0       -j   LOG  --log-prefix "FW: " --log-level 7

Затем вы можете просто отфильтровать эти сообщения, передав порог уровня dmesg:

dmesg --level=err,warn

— пик
источник

-7

Почему тебе не все равно? dmesgэто низкоуровневый инструмент для печати последних сообщений ядра, и вы попросили ядро записывать пропущенные пакеты.

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

— Колин Фиппс
источник