Newsgroup: it.comp.os.linux.sys
Titolo: Catturare Log di syslog in tempo reale

Ciao a tutti!
E da qualche giorno che sto scriptando un po' con Perl + mySQL per
catturare i log di iptables e salvarli in un DB...lo script funziona
semplicemente leggendo l' intero contenuto di /var/log/syslog e
tramite varie regex ottengo i dati che mi servono li salvo nel DB e
riscrivo il file /var/log/syslog 'screamato' dai log di iptables ormai
inutili.
Mi rendo però ora conto che dovendo controllare magari 100.000 righe
di log alla volta il metodo è un po' troppo pesante... e volevo
chidervi se sapete come fare per aggiornare il db nel momento stesso
in cui si genera il log...
Cerco di spiegarmi meglio...
se ho una regola iptables del tipo:
iptables -A INPUT -p tcp -s ! 
192.168.1.0/24
 -j LOG ProtoTCP
al verificarsi di una connessione mi genera un log tipo:
Sep 11 22:01:17 LinuxServer kernel: [18829358.512000]
[ProtoTCP]:IN=eth1 OUT= MAC=00:11:2f:cb:56:70:00:11:20:3a:79:aa:08:00
SRC=209.160.33.27 DST=192.168.1.1 LEN=104 TOS=0x00 PREC=0x00 TTL=52
ID=39775 DF PROTO=TCP SPT=36021 DPT=22 WINDOW=2172 RES=0x00 ACK PSH
URGP=0
come potrei fare in modo che al posto di venir scritto da syslog in un
file venga invocato il mio script passando magari come parametro la
stringa del log?
Spero di essermi spiegato bene...
PS: se a qualcuno serve lo script basta che chieda...

 catturare i log di iptables e salvarli in un DB
ulog già fa questo


Tempo fa gli avevo dato uno sguardo ma nn mi sembrava fare il caso
mio...
ma Ulog è in grado di eseguire uno script passandogli come parametro
il log stesso?


mm leggendo mi pare di capire che ulog è in grado di mettere i dati
direttamente nel db ma se io dovessi fare un elaborazione del dato
prima di metterlo nel db ulog ho paura che non basti più...corregetemi
se sbaglio.

 se sbaglio.
non sbagli

 stringa del log?
Poco consigliabile, anche se fosse: avresti una esecuzione a riga, e se
le righe arrivano ad un rate sufficiente, hai sotto il sedere una fork-bomb.
Passali allo script via pipe.

 semplicemente leggendo l' intero contenuto di /var/log/syslog
Dato che sai scriptare in perl, ti crei un demone che ascolta su socket unix
(Net::Server) al posto che leggere da file e usi syslog-ng per dirigere su
quella socket quel che ti interessa.
Un'oretta di lavoro e recuperi il 90% di quel che hai fatto.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 stringa del log?
Semplice: sostituisci Syslog con Syslog-NG e ti definisci una regola del
genere:
# E` il file di destinazione del log (puo` essere impostato anche per
avere una destinazione differente, leggi syslog-ng.conf)
destination df_iptables_log { file("/var/log/iptables.log"); };
# Nota: devi impostare lo stesso messaggio che hai impostato con
# l'opzione -j LOG (personalmente matcho tutto quello che incomincia con
# "---Firewall:" in modo da avere anche dei messaggi specifici per il
# tipo di filtro che ho impostato co iptables
filter f_iptables_log { match("---Firewall:"); }; filter
# Questa e` per non avere i messaggi di iptables in altri file (la parte
da me immessa, rispetto alla direttiva originale, e` quella dopo l'and)
f_kern { facility(kern) and not filter(f_iptables_log); };
# Idem come sopra
filter f_syslog { not facility(auth, authpriv)
                  and not filter(f_iptables_log);
};
# Imposto la regola di Syslog-NG per iptables in base alle direttive
# impostate sopra (puoi impostare piu` source, piu` filter, e piu`
# destination contemporaneamente)
log {
        source(s_all);
        filter(f_iptables_log);
        destination(df_iptables_log);
};
Morale della favola? Ho un file di log dedicato a tutto quello che
filtro con iptables e che voglio vedere nel log di sistema. Perche` tu
possa immettere i dati in un database (a tal proposito, ti consiglio
di usare PostgreSQL o Firebird invece di MySQL) basta che leggi il file
generato oppure lo stream rediretto tramite la direttiva destination
Enrico
P.S. il match() prende una espressione regolare

ok ci darò un occhiata, per ora grazie a tutti!

 stringa del log?
Spezzerei una lancia a favore di una soluzione asincrona in cui i
dati vengano memorizzati su file e solo dopo scritti su db. Penso
che sia piu' disponibile e resiliente d'un logging solo su db. Il
file lo metti in tail a 
sec.pl
 o al tuo script perl, ed e' fatta.
Valuta un file checkpoint per memorizzare lo stato del logging su
database, in modo che in caso di sua indisponibilita', il logging
possa proseguire su file e poi, quando il db torna su, riprendere
dal punto a cui era rimasto (vedi i waldo file per barnyard, come
esempio di funzionamento). Il blocco o la congestione del sistema
di logging su db non deve portare ad un blocco totale del logging
del tuo firewall e tantomeno ad una perdita di righe di log. Vedi
pipe non bloccanti, nel caso, e logging anche su file in locale. 
Con rsyslog puoi loggare in modo molto efficente su database e su
file di testo contemporaneamente senza tool esterni e con sistemi
di fallback sui target di logging effettivamente disponibili ma i
i log non li puoi smaneggare prima di scriverli su db AFAIK.
Contrariamente ad altri penso che mysql sia la scelta migliore in
applicazioni fortemente INSERT only, monoclient e senza uso delle
transazioni come questa. Tuttalpiu' valuterei sqlite, ma i log li
avresti solo in locale.
Fabio

 se sbaglio.
Pui sempre far scrivere ulog in una tabella temporanea da dove pesca il
tuo script per salvare in quella ufficiale.
Ciao, Micky
-- 
What's this hash prompt on my terminal mean?
Micky Del Favero  -  System Manager  &  BOFH

On 14 Set, 12:01, Micky <mi...@fcnz.zrfvan.arg> wrote:

ma quindi non c'è modo di attivare uno script al verificarsi di un
evento di log?
adesso ho per la testa lo script in perl per salvarmi i log ma se
volessi semplicemente usare 'beep -l 1000 -f 3000' quando iptables
logga come potrei fare?

 logga come potrei fare?
Si puo' fare con rsyslog ma sono meglio 
sec.pl
 o logsurfer o swatch.
Fabio



Puoi provare con un trigger nel database.
Ad esempio con PostgreSQL è possibile scrivere i trigger in Perl.
Saluti  Manlio Perillo

 - Mostra testo tra virgolette -
Ma quindi nulla che mi possa far eseguire un programma al verificarsi
si un evento loggato?

 si un evento loggato?
Come fatto notare da Skull, pensa nel caso in cui vengono scritti 500
eventi contemporaneamente: ti ritroveresti 500 istanze del tuo
applicativo a girare nello stesso momento, con conseguente richiesta
di risorse da parte dell'applicativo alla macchina che lo ospita. A
questo punto, molto meglio l'idea di ZiPMaN di utilizzare un socket
unix su cui poi redirigere la chiamata di log tramite syslog-ng
(l'applicativo istanziato e` uno, e le richieste sarebbero processate in
maniera sequenziale), oppure impostare un cronjob che vada a leggere un
file specifico ogni tot minuti, file in cui ovviamente syslog-ng
scrivera` automaticamente i dati che devono essere matchati, e che non
devono risultare negli altri file di log
Enrico

 di risorse da parte dell'applicativo alla macchina che lo ospita. A
Dipende da come viene gestito l'evento, non puoi generalizzare. per
esempio, syslog-ng esegue una copia del processo all'inizio, quando
parte, e poi invia tutti i messaggi a quell'unica copia (i dettagli
cambiano leggermente con le ultime release) mentre rsyslog, invece,
si comporta come descrivete. Ne risulta che uno funziona bene se si
vuole lanciare beep, l'altro nel caso si voglia usare come serve ad
alessandro, e senza il rischio di creare una "fork-bomb".
Fabio

 si comporta come descrivete.
Se lavori in *pipe*.
Io mi riferivo proprio alla modalità di cui chiedeva esplicitamente
Alessandro:
«come potrei fare in modo che al posto di venir scritto da syslog in un
file venga invocato il mio script passando magari come parametro la
stringa del log?»
Se vuoi passare ogni riga come *parametro*, non vedo altra via che una
esecuzione a riga... :-\

 mi 
sembrava che il quesito fosse piu' generico, abbastanza da giustificare 
l'inciso, soprattutto perche', in risposta, viene citato esplicitamente 
syslog-ng, tool per il quale non e' applicabile lo scenario di crescita 
incontrollata dei processi paventato (e tantomeno l'idea del parametro)
e dove viene proposta una soluzione complessa (quella basata su socket)
per implementare funzionalita' gia' presenti in syslog-ng stesso.
Fabio