Re: [ml] problema con log iptables

> il problema è che in seguito alla rotazione del file di log (fatto da me
> con uno script che stoppa syslog, svuota il file e fa ripartire il syslog)
> iptables smette di loggare sia su syslog che su kern.log.....altra cosa
> molto fastidiosa è che tutti i log mi vengono buttati sul terminale (intendo
> proprio sul monitor !!!!) su cui sto lavorando...

Fastidioso, eh? :-/ Comunque mi sembra che altri abbiano gia' esaurito
l'argomento.

> a questo punto vi chiedo un'altra cosa..... se volessi buttare tutti i log
> che mi genera iptables su un'altro file come posso fare ???

Un modo puo' essere quello di usare un diverso syslogd. Quasi tutte le
alternative disponibili consentono di cercare delle corrispondenze nel
messaggio di log con pattern da te predefiniti e d'instradare, poi, in
base ai match le righe di log verso diverse destinazioni. "Su un altro
file" sarebbe un caso particolare di quanto sopra.

Il gia' citato (da altri) syslog-ng forse e' la scelta piu' adatta, in
complesso, ma ci sarebbero anche altre soluzioni, come metalog [1], il
meno noto msyslog [2] e un po' di altri che al volo non ricordo (visti
ma mai usati).

Per il caso dei log di iptables, esistono anche delle alternative piu'
specifiche e dedicate, come il gia' citato ulogd ed il meno noto fork,
specter. Lo svantaggio piu' grosso e' che se vuoi loggare in remoto ti
devi accontentare di farlo su database (oppure devi passare per syslog
o chi per lui). Il vantaggio piu' grosso e' che puoi anche loggare nel
formato pcap, che aggiunge qualita' ai log in fase d'analisi e ti puo'
essere utile anche per registrare abitualmente il traffico al posto di
snort o tcpdump. I log diretti su file di testo "a la" syslog di ulogd
non sono sufficientemente dettagliati, non usarli (meglio specter, nel
caso).


Fabio

[1] no log su rete, ma un po' piu' "prestante" in locale e semplice da
    configurare; gerarchia di directory e file di log inusuale, e poco
    compatibile con strumenti di analisi precotti e inscatolati;
[2] supporto nativo per registrare i log su database (anche se la cosa
    sarebbe fattibile pure con syslog-ng, poco coding e un pochetto di
    sbattimento); controllo integrita' log; meno documentato/diffuso.