Le cattive notizie
Non direttamente, non nel modo in cui vuoi. È possibile specificare più uscite di allerta, come descritto nella sezione 2.6 del manuale. Tuttavia, questo semplicemente invierà gli stessi avvisi a più posizioni. Avrai ancora gli avvisi delle firme importate da ddos.rules
e log.rules
registrati insieme.
The Good News
Non temere, possiamo farlo funzionare. Quello che dovrete fare è creare più file di configurazione e avere ciascun registro separatamente. A seconda esattamente di come vuoi dividere il traffico, ci sono un paio di modi in cui puoi andare.
MultiConfig
Snort ha un meccanismo integrato per consentire l'elaborazione di flussi di pacchetti diversi su diversi file di configurazione. Questo può essere utile se segmenti le tue applicazioni in base alla rete o alla VLAN. Cioè, tutte le app di posta si trovano su una VLAN, i server Web su un'altra, ecc. I dettagli completi sono forniti in Sezione 2.10 del manuale, ma i bit più importanti da capire sono che dipende dalla VLAN o dalla rete e non possono esserci duplicati. Significa che questa è una configurazione valida,
config binding: /etc/snort/snort.conf-ddos net 192.168.100.0/24
config binding: /etc/snort/snort.conf-log net 192.168.200.0/24
ma non lo è.
config binding: /etc/snort/snort.conf-ddos net 192.168.100.0/24
config binding: /etc/snort/snort.conf-log net 192.168.100.0/24
Per utilizzare questa funzione nella tua situazione devi eseguire ddos.rules
contro un set di host e log.rules
contro un altro. Dubito che tu voglia seguire questo approccio.
Istanze multiple
Fino ad oggi lo snort è a thread singolo, quindi quando l'elaborazione è abbastanza intensa da utilizzare un processore completo, inizierà a rilasciare i pacchetti. Grazie a questo, troverai spesso sensori snort con diverse versioni di snort running. Generalmente questo funziona usando qualcosa chiamato PF_RING, che è come un bilanciamento del carico di pacchetti, o riducendo lo spazio di rete ed eseguendo una versione di snort per blocco. Quindi un'istanza di snortd
monitoraggio 192.168.1.0/25
e un'altra visualizzazione 192.168.1.128/25
. Nella maggior parte dei casi ogni processo userà lo stesso file di configurazione ma solo guarderà determinati indirizzi.
Possiamo adottare questo approccio e accenderlo è un po 'di testa lavorare nella tua situazione. Creiamo due file di configurazione e impostiamo le parti rilevanti in questo modo.
/etc/snort/snort.conf-ddos
output alert_syslog: LOG_LOCAL0 LOG_ALERT
include $RULE_PATH/ddos.rules
/etc/snort/snort.conf-log
output alert_syslog: LOG_LOCAL1 LOG_ALERT
include $RULE_PATH/log.rules
Quindi impostiamo il tuo motore syslog, riavviandolo dopo aver apportato le modifiche, naturalmente.
local0.alert /var/log/snort/alert-ddos.log
local1.alert /var/log/snort/alert-log.log
Ora quando esegui lo snort lo fai due volte, ognuno con l'opzione -c
. La prima volta useremo -c /etc/snort/snort.conf-ddos
e il secondo con -c /etc/snort/snort.conf-log
.
Ora dovresti avere due istanze di snortd
in esecuzione, una solo con le firme ddos.rules
e la registrazione su LOCAL0 e una con le firme log.rules
e la registrazione su LOCAL1. Finché syslog si sta comportando, dovresti fare in modo che i tuoi avvisi vengano registrati separatamente senza la co-mingling.