dmesg inondato di log del firewall

8

Nel mio iptables, ho una regola che registra i pacchetti rilasciati:

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

E in /etc/rsyslog.conf, ho un'altra regola che invia questi registri a un file dedicato /var/log/firewall.log.

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

Il & ~elimina i log immediatamente, in modo che essi non alluvione syslogo altri file di log.

Funziona bene, tranne per il fatto che si riempie dmesgdi quei log del firewall (non /var/log/dmesgma l'output del comando dmesg).

Esiste un modo per impedire che questi registri vengano visualizzati in dmesg?

logs iptables rsyslog

— Martin Vegter
fonte

Qual è il punto nel registrare tutto comunque?

— 0xC0000022L,

1

Non è davvero una buona idea registrare tutti i pacchetti rilasciati. La cosa migliore dell'eliminazione dei sintomi sarebbe quella di essere più specifici con la regola di registrazione. Ad esempio, non è molto saggio registrare alcun pacchetto che non sia correlato a nessuna connessione e che non faccia nulla di speciale (come l'avvio della connessione). Sarebbe molto meglio ridurre questo aspetto a cose rilevanti come "L'host A voleva connettersi alla porta B". Potenzialmente il numero di motivi per cui un pacchetto viene eliminato è enormemente maggiore del numero di motivi per cui lo si lascerebbe cadere per un motivo rilevante .

— Andreas Wiese,

1

@Andreas Wiese - Ho semplificato la mia regola per il bene di questa domanda. Le mie regole sono più sofisticate e specifiche. Ma comunque, la domanda è come prevenire dmesgl'inondazione, non sulle regole del firewall.

— Martin Vegter,

Vedi anche questa risposta sul demone di registrazione di Netfilter ulogd2. È così che ho risolto il problema.

— marzo

4

È possibile utilizzare l' NFLOGobiettivo anziché 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.

Tutto ciò di cui hai bisogno è un nfnetlink_logprogramma di registrazione capace. I messaggi andrebbero lì e il processo di userspace deciderebbe se registrare o meno il pacchetto.

Un'altra cosa che potresti provare sarebbe limitare la LOGregola a una soglia specifica:

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

Ciò comporterebbe in media 10 pacchetti al minuto. Ovviamente potresti adattarlo alle tue esigenze.

— Andreas Wiese
fonte

Non sono stato in grado di trovare alcuna informazione su come configurare i pacchetti di rsyslogregistro NFLOG. Ho bisogno di una soluzione che funzioni rsyslog.

— Martin Vegter,

2

@MartinVegter - NFLOG funzionerà con rsyslog. Per NFLOG, useresti ulogd (penso che ulogd2 sia necessario) come via di mezzo. Ascolterà sul socket netlink per ottenere i log e li consegnerà (come configurato) a syslog. Se ulogd2 non è disponibile, utilizzare ulogd (1.x) e il target ULOG.

— Christopher Cashell,

0

Potrebbe essere correlato al livello di registro che si sta utilizzando in iptables. A quanto ho capito dai livelli di registro della documentazione di rsyslog sono: "La priorità è una delle seguenti parole chiave, in ordine crescente: debug, informazioni, avviso, avviso, avviso (uguale a avviso), err, errore (uguale a err), critico, attento, emergere, panico (come emergere). " Che ne dite di provare a specificare il livello di registro in iptables usando il suo nome, ad esempio "avviso". Beh, mi serve bene per la pubblicazione senza controllo, poiché ora penso che non sia affatto il problema. Ho implementato uno schema simile a quello descritto sopra e ottengo lo stesso problema. Il mio kernel centos 7 è v3.10.0 e apparentemente dalla v3.5 sembra che la registrazione del kernel sia fatta usando / dev / kmsg e presumo che in qualche modo dmesg ottenga il suo input da lì.

— VaughanR
fonte

0

Dopo aver impostato il livello di registro su 7 con il comando:

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

Quindi puoi semplicemente filtrare questi messaggi passando la soglia di livello a dmesg:

dmesg --level=err,warn

— picco
fonte

-7

Perché ti interessi? dmesgè uno strumento di basso livello per stampare i messaggi recenti del kernel e hai chiesto al kernel di registrare i pacchetti rilasciati.

Configura il sistema syslog del tuo sistema per registrare i messaggi iptables in un file di registro separato dagli altri messaggi del kernel e usa i file di registro che scrive invece di dmesg.

— Colin Phipps
fonte