Re: [ml] NIDS: quale scegliere?

> Risultato: a tre giorni dalla messa online, la home page di Base non ce
> la fa nemmeno a caricarsi per darmi i grafici riassuntivi del traffico.
> Il DB server è in ginocchio: ad ogni chiamata il load average schizza a
> 2/3 (complici anche i miseri 256MB di RAM).

Trascuro considerazioni sul tuo ruleset ed altri aspetti che sono ignoti.

Relativamente a BASE ti direi che le possibili cause potrebbero essere la
gestione delle cache e delle statistiche. Se i problemi sono questi, puoi
provare ad aggiornare periodicamente la cache della risoluzione dei PTR e
la cache degli alert (vedi acid_ip_cache e acid_event) mettendo a crontab
l'esecuzione d'acid_maintenance.php chiamato con gli opportuni parametri.
Le statistiche della pagina di apertura, che possono essere pesanti, puoi
disabilitarle, cosi' come puoi disabilitare anche la risoluzione degli ip
e gli aggiornamenti della cache acid_event ad ogni apertura delle pagine,
lasciando gli aggiornamenti ai soli job schedulati o a manina. Se ti stai
chiedendo che cosa diavolo siano queste cache, dai una occhiata alle FAQ.
Quelle di ACID, intendo, che sono [per lo piu'] valide anche per BASE :-)
... e archivia e/o cancella frequentemente gli eventi nel database, cosi'
da tenere al minimo la quantita' di dati da gestire.

Uhmmm... dai anche uno sguardo se per caso hai configurato il logging sia
degli alert, sia dei log sullo stesso db: questo ti porta ad avere eventi
duplicati e, quindi, molti piu' eventi da gestire con BASE. Se vuoi avere
anche gli alert, oltre ai log (che darei per scontati), su mysql, sarebbe
meglio registrarli su un db distinto. Se proprio vuoi farlo, intendo. Nel
caso, valuta di usare mudpit (vedi oltre).

Rimembra che l'analisi del traffico dns e' uno dei modi per verificare se
1) c'e' un nids e 2) dove si trova: vedi tu se la cosa e' un problema nel
tuo caso.

> 1) Snort+Base è una soluzione ottimale?

Ottimale per che cosa? Puo' essere comodo, ma anche scomodissimo. In ogni
caso, come ti hanno gia' detto, valuta l'ipotesi di disaccoppiare snort e
il database mediante l'inserimento di barnyard o mudpit. Le differenze le
trovi sul sito di mudpit. In particolare, elimina le doppie registrazioni
di alert e log (vedi sopra) consentendoti di avere tutte le info in un db
solo e senza duplicati. Sia barnyard, sia mudpit gestiscono male i cid o,
per lo meno, li gestiscono diversamente da snort (che gia' non e' un gran
che) e in modo potenzialmente incompatibile con procedure d'archiviazione
e storicizzazione degli eventi eventualmente gia' in essere. O le rivedi,
o patchi i due aggeggi di cui sopra e li fai comportare come snort.

A mio parere acid/base sono un discreto strumento per analizzare i log di
snort, ma quando gli alert sono tanti diventano scomodi, perche' mostrano
un output troppo poco "aggregato"[1] degli eventi, senza opportuni filtri
sulla loro priorita', sia intesa nel senso di snort, sia intesa nel senso
delle _tue_ priorita'. A volte, un bello script in perl da usarsi sui log
in formato testo o un correlatore tipo sec possono ben coadiuvare.

> 2) E'consigliabile separare Snort dal DB server?

Le prestazioni posson migliorare. Affidabilita' e disponibilita' no. A te
l'ardua sentenza. Puoi anche separare il database dal server http con cui
esegui il frontend php.


Fabio

[1] non mi viene un altro termine altrettanto sintetico :-(

PS: temo d'avere mischiato un po' l'uso del termine "alert", senza tenere
    conto delle accezioni in cui lo si intende in snort ed in BASE; spero
    che il contesto lo chiarisca.