dmesg inundado con registros de firewall

8

En mis iptables, tengo una regla que registra los paquetes descartados:

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

Y en /etc/rsyslog.conf, tengo otra regla que envía estos registros a un archivo dedicado /var/log/firewall.log.

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

El & ~borra los registros inmediatamente, para que no se inunden syslogu otros archivos de registro.

Esto funciona bien, excepto que se inunda dmesgcon esos registros de firewall (no /var/log/dmesgsino la salida del comando dmesg).

¿Hay alguna manera de evitar que se muestren estos registros dmesg?

logs iptables rsyslog

— Martin Vegter
fuente

¿Cuál es el punto de registrar todo de todos modos?

— 0xC0000022L

1

Realmente no es una buena idea registrar todos los paquetes descartados. Mejor que eliminar los síntomas sería ser más específico con su regla de registro. Por ejemplo, no es muy aconsejable registrar ningún paquete que no esté relacionado con ninguna conexión y no haga nada »especial« (como el inicio de la conexión). Sería mucho mejor reducir esto a cosas relevantes como »Host A quería conectarse al puerto B«. Potencialmente, la cantidad de razones por las que se descarta un paquete es enormemente mayor que la cantidad de razones por las que lo descartaría por una razón relevante .

— Andreas Wiese

1

@Andreas Wiese: he simplificado mi regla en aras de esta pregunta. Mis reglas son más sofisticadas y específicas. Pero de todos modos, la pregunta es cómo evitar que dmesgse inunde, no sobre las reglas del firewall.

— Martin Vegter

Consulte también esta respuesta sobre el demonio de registro de Netfilter ulogd2. Así es como resolví el problema.

— mivk

4

Podría usar el NFLOGobjetivo en lugar de 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.

Todo lo que necesitas es un nfnetlink_logprograma de registro capaz. Los mensajes irían allí y el proceso del espacio de usuario decidiría si registrar el paquete o no.

Otra cosa que podría intentar sería limitar la LOGregla a un umbral específico:

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

Esto registraría en promedio 10 paquetes por minuto. Por supuesto, puede ajustar esto a sus necesidades.

— Andreas Wiese
fuente

No pude encontrar ninguna información sobre cómo configurar rsyslogpara registrar NFLOGpaquetes. Necesito alguna solución que funcione rsyslog.

— Martin Vegter

2

@MartinVegter - NFLOG funcionará con rsyslog. Para NFLOG, usaría ulogd (creo que se necesita ulogd2) como intermediario. Escuchará en el zócalo de enlace de red para obtener los registros y los entregará (según lo configurado) a syslog. Si ulogd2 no está disponible, use ulogd (1.x) y el objetivo ULOG.

— Christopher Cashell

0

Puede estar relacionado con el nivel de registro que está utilizando en iptables. Según tengo entendido, los niveles de registro de la documentación de rsyslog son: "La prioridad es una de las siguientes palabras clave, en orden ascendente: depuración, información, aviso, advertencia, advertencia (igual que advertencia), error, error (igual que error), crit, alert, emerg, panic (igual que emerg) ". ¿Qué hay de tratar de especificar el nivel de registro en iptables utilizando su nombre, es decir, 'aviso'? Bueno, me sirve para publicar sin verificar, ya que ahora creo que ese no es el problema en absoluto. Implementé un esquema similar al descrito anteriormente y obtengo el mismo problema. Mi centos 7 kernel es v3.10.0 y aparentemente desde v3.5 parece que el registro del kernel se realiza usando / dev / kmsg y supongo que dmesg de alguna manera obtiene su entrada desde allí.

— VaughanR
fuente

0

Cuando haya establecido el nivel de registro en 7 con el comando:

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

Luego, simplemente puede filtrar estos mensajes pasando el umbral de nivel al dmesg:

dmesg --level=err,warn

— pico
fuente

-7

¿Por qué te importa? dmesges una herramienta de bajo nivel para imprimir mensajes recientes del núcleo, y usted solicitó que el núcleo registrara los paquetes descartados.

Configure el sistema syslog de su sistema para registrar mensajes de iptables en un archivo de registro separado de otros mensajes del núcleo, y use los archivos de registro que escribe en lugar de dmesg.

— Colin Phipps
fuente