scelto di segnalare questi pacchetti con una facility dierente rispetto a quelli di Linux, essendo i log molto dierenti tra loro, sia nella forma che nella dimensione: la facility utilizzata è local0.
Le macchine da analizzare erano molte, ma la maggior parte di esse è colle-gate all'albero LDAP, quindi il problema non si è posto per quelle macchine. Al contrario , per i server che non vanno collegati al dominio per ragioni di sicurezza e per evitare accessi indesiderati, si è intrapresa la stessa strada delle macchine Linux, creare 4 account nominali ed impostare l'invio da ogni macchina, impo-stando lo Snare presente volta per volta, in base alle necessità della macchina (se è presente Oracle, Postgresql o SQL Server sono necessari Event ID dierenti). Sul PDC è stata attivata la security di base, attivando quindi il logging degli ac-cessi di ogni utente presente in azienda, anche se nel nostro caso verranno ltrati questi dati e memorizzati unicamente gli accessi relativi agli amministratori.
Gli Event Id di windows associati alle sessioni (inzio e ne) per le macchine normali sono :
515, 528, 529, 538, 540, 552, 576, 577, 646, 672, 673, 674, 675, 680, 6006, 6005, 5805.
Mentre per monitorare i login eettuati tramite l'LDAP è necessario impo-stare, sul PDC, anche gli eventi :
681, 682, 683, 1009, 1016, 1013, 1029.
8.4 Raccolta dai Dababase
Gli accessi ai Database, col ruolo di amministratore, sono stati loggati utilizzan-do sistemi built-in dei DBMS, come per i Sistemi Operativi sono state create le user personali (una per amministratore), la facility scelta per i log provenienti da macchine linux è local1, mentre per le macchine Windows non è stato pos-sibile dierenziare l'invio dei log per facility, sarebbe stato pospos-sibile creare dei meccanismi di selezione cartella ltrando più approfonditamente i pacchetti in arrivo, ma ho scelto di scartare questa ipotesi di lavoro a causa di un crash del Syslog avvenuto nel momento in cui il volume dei pacchetti in arrivo è aumentato assieme alle regole per la loro memorizzazione, per rimediare ho sempil cato le regole e così non si sono più veri cati problemi, quindi ho ridotto più possibile i ltri e le regole in generale, rimandando così questo ltraggio al momento della lettura dei log (alla suite 'auditing').
8.4.1 Mysql
Mysql è presente unicamente su macchine Linux, l'attivazione del logging è rela-tivamente semplice, è su ciente decommentare la riga relativa al logging sul le di con gurazione mysql/my.cnf, e successivamente riavviare il daemon di mysql.
Mysql, sfortunatamente, non ha la capacità di inviare i log direttamente al logger di sistema, ma unicamente su le, si è creata la necessità di fornire al logger di sistema ogni riga utile (connect e disconnect) che mysql scriveva sul proprio log le; ho quindi studiato il funzionamento delle pipe in Linux ed ho creato un daemon che ha il compito di leggere il le di log e di inoltrare ogni evoluzione di questo le ad un egrep che seleziona unicamente le righe relative ad inizio o ne sessione di un utente all'interno del DB, queste righe vengono poi inoltrate al logger di sistema utilizzando come facility:local1 e tag identi cativo dell'applicazione:mysql. Il daemon creato è stato inserito nel runlevel di default, e all'avvio del sistema, per assicurarsi che anche in caso di riavvio il servizio parta, e che, anche se viene fermato in qualche modo, di default Linux lo riavvia. Riporto qui lo script che eettua tale controllo :
Blocco di codice 8.19
tail -f /tmp/mysql | egrep 'Connect|Quit' | logger -p local1.info -t mysql &
Lo script funziona grazie alle Pipe di Linux, con le quali è possibile creare sequenze di comandi, il primo passa il proprio output al secondo, e così via no all'ultimo, ad ogni passaggio è possibile creare, leggere o modi care le, inviare Mail o eettuare altri comandi, nel nostro caso si legge, si ltra e si passano i dati al loggeri di sistema. Il logger riceve questi messaggi e li inoltra a sua volta al centro di raccolta, indicando propriamente l'header del pacchetto.
8.4.2 PostgreSQL
É stato attivato il logging di base, che invia le informazioni relative ad acces-si e disconnesacces-sioni al logger di acces-sistema (acces-sia in Linux che in Windows), da qua Linux legge il messaggio e lo inoltra al centro di raccolta attraverso le corrette inmpostazioni di Syslog mentre, in windows, SNARE ha impostato l'id relativo agli eventi Postgres, oltre a questo, in entrambi i sistemi di logging sono stati impostati termini di ricerca : Connect o Disconnect, così da inviare solo dati eettivamente utili e non inondare la rete con ogni query eseguita, soprattutto perchè spesso queste sono molto voluminose.
8.4 RACCOLTA DAI DABABASE
8.4.3 SQL Server
Sui SQL Server, presenti unicamente su macchine Windows, è stata con gurata la security di base, attivando il logging di tutti gli accessi eettuati, inoltre sono state genereate le credenziali che rendono identi cabile l'accesso al DBMS. Su SNARE, preventivamente installato sulla macchina per il logging della security, sono stati impostati gli eventi corretti nel ltro e l'inoltro verso il centro di raccolta. Il riavvio dei SQLServer è stato piani cato, infatti questi Database sono collegati a servizi che devono essere forniti 24 ore su 24, l'interruzione di questi, anche se solo per brevi periodi e senza una valida motivazione, avrebbe causato problemi all'azienda, è stato quindi piani cato un riavvio durante il cambio sede che a breve dovrà avvenire.
Snare rileva questi dati nell'Eventlog di sistema, in particolare nella sezione riservata alle applicazioni, da là è stato impostato il ltraggio di tutti gli eventi riguardanti SQL Server, per rilevare eventi provenienti dai Database è su cien-te creare una regola su Snare che monitori unicamensu cien-te il modulo Application dell'EventLog.
L'event ID associato a SQL Server è il 17055, con match del codice di login: 18453 o di logout: 18454.
8.4.4 Oracle
Per i database Oracle, presenti in macchine Windows, sono stati impostati, 4 ac-count di accesso e con le relative policy di auditing necessarie, gli aac-count sono stati dotati di privilegi amministrativi, agendo quindi come l'utenza Administrator, ma associabile ad una persona sica. L'istanza di Snare installata sulla macchina é stata con gurata per eettuare l'invio degli eventi Oracle verso lo Zabbix.
Snare comunque rileva gli accessi degli amministratori grazie alla peculiarità della security dei Databse Oracle, infatti questi, di default, eettuano il logging di ogni accesso eettuato con credenziali da 'Super User', includendo nell'insie-me amministratori e gestori del database, cioè chiunque abbia la possiblità di eettuare operazioni di modi ca strutturale o addirittura eliminare tabelle, non vengono invece rilevati gli accessi che hanno le credenziali per eettuare unica-mente caricamento dati o visualizzazione.
8.4.5 Exchange
L'attivazione della policy di sicurezza su Exchange è da eettuare utilizzando gli strumenti messi a disposizione da Windows : in modo gra co In particolare si eettua con la seguente sequenza di comandi : Gestore sistema Exchange
1. Gruppi amministrativi 2. servere
3. NomeServer
4. tasto dx sul serverdi interesse 5. Proprietà
6. registrazione Diagnostica 7. MSExchangeIS
8. private o cassetta postale
9. Accessi = minima; Controllo accessi = minima
La selezione degli eventi corretti è avvenuta analizzando l'event Log di Windows ed impostandoli nell'istanza di Snare presente.