Newsgroup: it.comp.sicurezza.varie
Titolo: ACIDlab e logsnorter

Uso oramai da un po' di tempo snort unito ad ACIDlab per l'analisi degli
alert. Ispirato dall'articolone su L&c, ho deciso di buttare in ACID anche
i log di iptables tramite logsnorter (che nemmeno conoscevo, pensa te...).
[ Prima facevo girare fwlogwatch sugli stessi e mi andavo a guardare a
manina le hits più rilevanti... ]
Solo non mi riesce di ottenere granchè...
io ho il mio bel file di log dove finiscono solo i log di iptables.
Metto logsnorter in tail su quel file, dopo avergli impostato i vari nomi
utente ecc...
Ma se osservo acidlab, non vedo acquisire alcunchè...
Dato che in linea di massima mi pare che tutto il resto sia ok, non
vorrei aver frainteso l'utilità di loggare sul db di acidlab: qualcuno
che lo usa mi può dire per cortesia cosa dovrei aspettarmi esattamente???
;-)
-- 
Emanuele Balla |  ... aka Skull
---------------+
"And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports
on it, you know they are just evil lies." (By Linus Torvalds)

 Ma se osservo acidlab, non vedo acquisire alcunchè...
Usi --log-prefix?
Fabio

Sgranocchiando il cranio di Fabio Panigatti, vi trovai inciso:

Già... perchè, ci sono controindicazioni?!?
Uno skull e fwanalog
-- 
Emanuele Balla   aka Skull
+----------------------------------------------------------------------+


 Già... perchè, ci sono controindicazioni?!?
... ([^\s]+) kernel: IN=(\w+[0-9]+) ... 
             ^^^^^^^^^^^
Si, a quanto pare. Ma nulla di irresolvibile,
direi :-) ... sempre che sia questo il motivo
del tuo malfunzionamento.
Fabio

 sia questo il motivo del tuo malfunzionamento.
Hmmm... anche te non hai tutti i torti... :-P
Ho eliminato i prefix... non funziona, ma almeno adesso logsnorter dice
che non funziona ;-)
THX, mi rimetto a spulciare ...


 
Ok, funge... almeno... piů o meno ;-)
Pare che logsnorter non gradisca la presenza del campo MAC nei log di
iptables... il che significa che i pacchetti rifiutati dalla chain di
input non mi vanno a finire nel db...
In effetti spulciando logsnorter, non prevede questo campo se non nei log
di bastille... :-P
O sono io che ho una versione antidiluviana di logsnorter ( ma la 0.2 č
l'unica che ho trovato in giro, anche sui siti ufficiali...) oppure non č
molto mantenuto...
Mo' vedrň se ho tempo e voglia di correggerlo... Intanto almeno
funziona... quasi...
Ciao e grazie...


 funziona... quasi...
Si, in effetti deve essere piuttosto semplice meterci una pezza.
Fabio

             ... ([^\s]+) kernel: \w+ IN=(\w+[0-9]+) ...
Già, è quello che intendevo dicendo "vedo se ho tempo e voglia di
rappezzarlo..."
Anche perchè aggiungere la regexp per il prefix vuol dire aumentare il
numero dei campi che poi va a matchare, slittando i posizionali con cui
li brinka.
Se poi consideri che il prefix può avere dentro degli spazi, il tutto si
complica un poco (certo, potrei adattare i miei prefix a non avere
spazi... ma se devo farlo, preferisco farlo bene ;-) )
Ciao...


 spazi... ma se devo farlo, preferisco farlo bene ;-) )
Se usi '.*' e non lo metti tra parentesi ti meccia anche i prefix
composti di piu' parti e non ti dovrebbe far slittare gli indici.
Fabio

 Se usi '.*' e non lo metti tra parentesi
si può anche usare (?<pattern>), per usare le parentesi senza che venga 
salvato il risultato del matching
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.0. C, C++ and ASM developers
                               and beta testers are welcome!