Provo a mettere nero su bianco i test effettuati per l’adeguamento al provvedimento sugli amministratori di sistema emanato dal Garante Privacy la cui scadenza è fissata al 15 dicembre 2009. Ricordo brevemente che, fra le altre cose, il provvedimento richiede la registrazione e conservazione per almeno sei mesi dei log di accesso di ogni account degli amministratori di sistema. Esistono molti sistemi a pagamento che possono fare questo, ma perché spendere se possiamo adeguare i nostri sistemi senza dover acquistare costose licenze software? Ecco dunque, dopo gli spunti di discussione pubblicati mesi fa, dove semplicemente accennavo a quali strumenti potessero essere utilizzati, una traccia operativa per creare un sistema di log centralizzato per sistemi sia Windows che Linux basato su Debian. Intendiamoci. E’ solo una traccia, magari si può desiderare di implementare ulteriori livelli di sicurezza, come ad esempio la trasmissione dei log su connessione cifrata. E’ comunque un punto di partenza e sufficiente per piccole realtà con esigenze limitate.
Ricordo a questo proposito che il provvedimento non prevede specifiche tecniche, lasciando ad ogni titolare di trattamento la scelta su come implementare quanto richiesto.
Per essere compliant alla normativa, ogni utente e quindi ogni amministratore di sistema deve avere il proprio account. Per abilitare utenti diversi ad effettuare operazioni che richiedono i poteri di root si può abilitare il comando sudo, creando un gruppo apposito (su Ubuntu esiste già, è il gruppo admin) e modificando opportunamente con visudo i diritti di root per tale gruppo. Ad esempio:
| $ sudo visudo
# User privilege specification root ALL=(ALL) ALL # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL |
Ovviamente il nome del gruppo di utenti abilitati può essere scelto liberamente. In alcuni sistemi il nome di default è wheel. Quello che resta da fare è aggiungere gli utenti al gruppo admin usando useradd se l’utente deve essere creato da zero oppure usermod se l’utente esiste già.
Su sistemi windows è necessario impedire l’utilizzo dell’accesso come amministratore per il normale uso.
E’ appena il caso di ricordare che il log degli accessi amministrativi va registrato non solo per i server ma anche per i sistemi client se su queste macchine si gestiscono dati personali.
Syslog è il demone installato di default per gestire i log di sistema . Dobbiamo quindi sostituire syslog con un software che abbia delle funzioni in più. Per fortuna su Debian 5 (lenny) rsyslog è il demone di log installato di default.Una alternativa potrebbe essere syslog-ng. Entrambi i software permettono di ricevere i log da server remoti anche via ssl e registrarli su un db come (ad esempio, ma non solo) Mysql.
Su Ubuntu, ad esempio, l’installazione si effettua con il semplce apt-get install rsyslog.
Per abilitare la ricezione dei log da remoto va modificato sul log server il file di configurazione /etc/rsyslog.conf.
Invece il file /etc/default/rsyslog va modificato solo in caso vada mantenuta la compatibilità con vecchi sistemi, altrimenti non va toccato.
Nel file /etc/rsyslog.conf del log server vanno decommentate le righe sotto riportate per mettere il demone in ascolto sulla porta 514 UDP. Attenzione, se il traffico fosse molto elevato, si rischia di perdere delle righe di log. In questo caso va usato il protocollo TCP o RELP.
| # provides UDP syslog reception
$ModLoad imudp $UDPServerRun 514 |
Fatte queste modifiche si riavvia il demone con
| /etc/init.d/rsyslogd restart |
e si verifica che sia effettivamente in ascolto sulla porta UDP 541 con
| netstat -lpu | grep rsyslogd |
che deve mostrare qualcosa di simile:
| udp 0 0 0.0.0.0:514 0.0.0.0:* 2222/rsyslogd |
Per attivare l’invio del log al rsyslog remoto su ogni macchina linux che deve essere loggata va modificato il file /etc/rsyslog.conf modificando la riga
| auth, authpriv.* /var/log/auth.log |
in
| auth, authpriv.* @192.168.1.1 (mettere l’ip del server rsyslog centralizzato) |
La chiocciola davanti all’indirizzo IP indica a quale host deve essere inviato il log.
Per windows ho testato Snare Agent for Windows, un pacchetto open source che installa un servizio per il log degli eventi su windows ed è amministrabile tramite una pagina web. L’installazione si limita al solito doppio click sull’eseguibile, all’impostazione della password ed alla scelta se permettere o meno l’accesso remoto alla pagina di configurazione del servizio. Per effettuare la configurazione è sufficiente puntare il browser su localhost:6161. Utente e password di default sono snare/snare, da cambiare immediatamente.
La configurazione da impostare per avere il log remoto è sulla pagina network. Basta impostare Destination Snare Server address con l’indirizzo ip del server di log e come destination port 514. Attivare Enable Syslog Header e selezionare come syslog facility auth, con livello notice.
Se tutto è andato bene, adesso nel file /var/log/auth.log verranno registrati login, logout ed errori di login delle macchine configurate.
Tenete presente che i log sistemi windows sono prolissi e bisogna saperli leggere. Gli eventi vengono identificati tramite un codice (ID Event) che assume il valore 528 per il login e 538 per il logout e distinguono gli accessi locali dagli accessi remoti tramite la variabile “Type” che ha valore 2 per accesso locale e valore 3 per accesso effettuato via rete. Vi sono inoltre vari altri ID e Type legati ad altre situazioni (p.e. errori di login) ed eventuali problemi (quale il mancato log degli eventi con ID 538 al momento della disconnessione). Trovate qui, qui,qui e qui alcuni articoli Microsoft con informazioni in merito.
Una alternativa a Snare Agent può essere ntsyslog, con la differenza che non può essere amministrato da remoto via pagina web come invece Snare Agent.
L’installazione di ntsyslog2 è come d’uso molto semplice. E’ sufficiente scaricare il file di installazione msi e lanciarlo con il classico doppio click per installare il servizio ntsyslog.
La configurazione si fa tramite il programma NTSyslogCtrl.exe (viene creato uno shortcut sul desktop). Selezionare il computer, scegliendo il pc sul quale è installato il servizio. Impostare il server di log tramite il bottone “Syslog Daemon” . Dal menu a scomparsa scegliere Security quale eventlog quindi cliccate sul bottone eventlog per selezionare quali eventi inviare al server remoto. Si può quindi avviare il servizio.
Dato che il provvedimento del Garante richiede il log dei tentativi di accesso, riusciti o meno che siano, è bene disattivare l’invio degli eventlog sistema, applicazioni e internet explorer.
Attenzione: ho notato che su alcuni sistemi Windows è disabilitata la funzione di event log, pertanto nessun evento relativo agli accessi viene registrato. Per attivare la registrazione (e l’invio al syslog remoto) degli eventi di accesso è necessario entrare come administrator sul pc, aprire il pannello di controllo, Strumenti di Amministrazione, Criteri di protezione locali, Criteri locali, Criteri controllo e verificare che sia attivato il flag “Controlla eventi di accesso“. Esiste anche “Controlla eventi accesso account” ma questo controllo non registra i logout.
Altre questioni da valutare sono relative alla gestione dei log una volta registrati sul nostro log server. Ad esempio per adeguarsi al requisito della immodificabilità si può pensare di copiare periodicamente il log su di un supporto non riscrivibile, validando i file con un hash. Ricordatevi di tenere file ed hash in luoghi separati. Un’altra possibile soluzione è avere un log server al quale l’amministratore di sistema non ha accesso ne logico ne fisico. Già sento le risate…ma ricordate che quanto scritto fino qui è solo un contributo, non la soluzione al problema.
Ogni soluzione deve essere calata nel contesto in cui si opera, e deve essere parte di un sistema di Governance dell’IT che comprenda strategie di gestione e di controllo.
L’amministratore di sistema, il professionista IT non deve essere lasciato da solo a “far funzionare il pc” ma deve essere considerato come parte integrante del sistema azienda. In questa ottica, il provvedimento del Garante Privacy deve essere visto come uno stimolo alla diffusione di una maggiore attenzione da parte delle aziende e dei dirigenti verso quelle attività a torto considerate solo come “tecniche” e lasciate alla buona volontà degli informatici.
Infine un “grazie” a Maurizio, che con il suo post mi ha stimolato a scrivere questo articolo.
Addendum: Si è andato creando una specie di “circuito” di soluzioni tecniche per il problema dei log degli Ads. Bella questa cosa.
Ne approfitto quindi per segnalare anche la soluzione proposta da Ivan Zini
Vi chiedo :
Nella mia azienda sono stati nominati Responabili del trattamento tutti i Dirigenti
di una specifica Area aziendale e il Consigliere Delegato.I membri del Consiglio di Amministrazione, il Presidente è preferibile nominarli Incaricati o Responsabili ?.
L’ A.d.S. e preferibile nominarlo Responsabile o Incaricato ?
Grazie per i vostri consigli.
In risposta a Xilesit:
La scelta della nomina a responsabile o incaricato va fatta in base all’effettivo “organigramma privacy”, ovvero se la persona ha la responsabilità (vedi art. 29 del codice) o meno sulle modalità di effettuazione del trattamento. Se Non ha una mansione “di vigilanza” sul trattamento, è un semplice incaricato anche se è un dirigente. Idem per gli AdS.
@Paolo Giardini Potresti gentilmente indicare il link che tratta la questione del Titolare che nel contempo è anche amministratore di sistema?
in risposta ad Olga:
Nelle FAQ del Garante su AdS, risposta n. 3, trovi che nel caso limite di titolare che sia anche unico amministratore di sistema, il provvedimento non si applica.
Ecco il link alla FAQ n.3
@Paolo Giardini Ti ringrazio molto sia per la risposta che per utilissimo articolo.
Non voglio fare pubblicità, ma andate a vedere il prodotto legallogger, interamente basato su opensource
mysql/syslog-ng/openssl
registra i file di log e vi mette marcatemporale rilasciata dalla camera di commercio dunque valida legalmente, e contando che le marche temporali costano 30 cents ognuna il costo di 30 €/mese non mi sembra insostenibile, soprattutto perche toglie da ogni responsabilità
l’amministratore di sistema.
noi lo abbiamo adottato e a parte qualche problema durante la fase di setup (scambio di certificati ssl etc…) lo abbiamo messo su in mezza giornata e ora siamo in regola ….
ciao
in riposta a Raffella:
Ho dato un’occhiata al sito e mi sembra che riporti alcune inesattezze interpretative del provvedimento del Garante.
Non esiste alcun obbligo di apposizione di marca temporale sui log ne si deve “registrare e conservare i log delle attività degli Amministratori di Sistema” ma solo login e logout (ed eventuali condizioni di errore).
Inoltre non è corretto dire che ” la normativa (al punto 4.1 ) pone anche il responsabile o l’addetto al trattamento dei dati sensibili allo stesso livello dell’amministratore di sistema, ” .
Magari si tratta solo di come sono stati espressi i concetti, ma così come scritto possono portare a conclusioni errate.
Ultima cosa: attenzione al fatto che i log vengono conservati presso il server del fornitore del servizio; questo deve essere considerato come trattamento esterno e regolato di conseguenza.
Pingback: RSS Week #78: letture per il weekend - Matteo Moro
Blog molto interessante, ho ancora un problema da risolvere con rsyslog: installato phologcon su ubuntu mi invia error 15 (non riesce ad aprire syslog). Potete darmi una mano?
grazie cmq
Francesco
in risposta a Francesco
Immagino che PphLogCon, o meglio l’utente che fa girare Apache, non abbia i diritti di lettura del file syslog. Prova a verificare questa cosa.
Nel caso, qui trovi una soluzione.
in risposta a Paolo Giardini:
Ti ringrazio, adesso ci provo.
Francesco
Rilasciata una nuova versione freeware del programma log196 per le piccole aziende e studi adatto solo per piattaforma Microsoft.
Ho trovato l’articolo molto interessante,
anche se alla fine non sono riuscito a trovare una soluzione che mi convincesse:
cosa ne pensate di Business Log di sysadmin.it ? non e’ freeware, ma ha un costo decisamente accettabile: 199 euro all’anno e forse il fatto di pagare qualcosa tutela di piu’ dal punto di vista dell’assistenza e dal punto di vista legale:
pensavo di adottarlo ma volevo qualche riscontro prima
ciao e grazie
Roberto
Ciao, ottimo articolo! Lo utilizzerò come guida 😉 Un domanda però, forse banale; alla fine dell’articolo scrivi “L’amministratore di sistema, il professionista IT non deve essere lasciato da solo a “far funzionare il pc” ma deve essere considerato come parte integrante del sistema azienda.”
Ma credo che nella maggior parte delle aziende sarà proprio questa figura a realizzare questo sistema di controllo, in quanto una delle poche persone o magari l’unica con le conoscenze tecniche adeguate, quindi potrebbe essere semplice per lui aggirare il sistema o sbaglio? Mi sfugge qualcosa?
Grazie.
Ciao, un’informazione, ho impostato tutti i parametri di rsyslog nel server ubuntu e installato snare agent su una macchina windows, ma non vengono scritti i log in remoto.. Credo sia un problema di permessi, ma non ho capito come far dialogare l’utente windows con il server linux.. Grazie! 🙂
In risposta a Marco
Si, certamente questo aspetto non sfugge a nessuno, tanto meno al Garante che nelle FAQ ha preso in esame il livello di sicurezza richiesto concludendo che in pratica la sicurezza di un sistema di controllo così come previsto dal provvedimento non è e non può essere garantita. Ma come ho detto in un seminario qualche giorno fa, dareste le chiavi di casa al primo venuto?
In risposta a Marco
Ciao.
Il sistema così come descritto nell’articolo funziona; sei sicuro di aver impostato correttamente il server di syslog sull’agent? Verifica con uno sniffer di rete se i pacchetti vengono spediti, così individui dove si trova il problema.
Ciao, grazie della risposta, e problema risolto 😉
Se l’amministratore deve avere accesso al log server, perchè lo gestisce lui, quali potrebbero essere le soluzioni per garantire l’immodificabilità?
La garanzia dell’inalterabilità dei log è un requisito che lo stesso Garante ha reso meno stringente, vedi la faq 12, dove scrive che questo “può essere ragionevolmente soddisfatto con la strumentazione software in dotazione, nei casi più semplici, e con l’eventuale esportazione periodica dei dati di log su supporti di memorizzazione non riscrivibili.”. Da qui in poi, vale tutto, fino alla marca temporale e firma digitale. La cosa irrinunciabile è un documento, istruzione, lettera di incarico che specifichi bene le mansioni e le modalità di conservazione dei log.
Caro Paolo,
disposizioni per Amm. di Sist.: devo mantenere i log degli ultimi sei mesi che documentano le fasi di login/logout (con successo e con errore) degli AdS ai pc, server e database dell’azienda. Sta al Titolare del tratt. decidere se masterizzare tali log, crittografare i dati, ecc.
Domande:
1- corrisponde a quanto sai?
2- cosa dovrei fare per i casi in cui l’AdS dovesse entrare localmente in un pc o server, perchè fuori dal dominio o per altri determinati motivi? L’agente, ad es. Snare, dovrebbe comunque registrare tale accesso?
3- anzichè Snare, o altri client, potrei sfruttare Log Parser (che però non conosco bene)?
4- dovendo adeguarmi anche alle disposizioni per provider (sul data retention), e dovendo questa volta crittografare i dati, verificarne l’integrità, ecc., potrei utilizzare (migliorandolo) ciò che si fa per le dispozioni degli AdS?
5- conosci quest’ultima normativa?
Grazie
Ciao.
Riesco solo ora a rispondere alle domande di Alias…
1) “Sta al Titolare del tratt. decidere se masterizzare tali log, crittografare i dati, ecc.”
Beh, detto in parole povere è così, ma bisogna tener presente il requisito di inalterabilità e immodificabilità dei log registrati.
2) Vediamo il caso di login su un pc non in rete o comunque dove non è installato un agente per il log remoto.Le disposizioni non cambiano, è sempre necessario effettuare il log dell’accesso ecc. Il discriminante sta nella verifica preventiva sulla presenza o meno di dati personale in tale computer o se il computer viene usato per effettuarne il trattamento. Se non vi è presenza di dati personali, non si applica il provvedimento sugli AdS.
3) Ovviamente per adeguare il tuo sistema al provvedimento poi usare il metodo che preferisci, non vi sono prescrizioni tecniche in questo senso.
4-5) si, conosco la normativa ma è molto più stringente e richiede attività di livello più elevato rispetto al provvedimento sugli AdS. Personalmente non applicherei quanto richiesto per la data retention ai log per AdS.
La soluzione è interessante e anche abbastanza facile da implementare, tra le altre cose esistono distribuzioni leggere che sono già pronte per questo tipo di servizio (zeroshell ad esempio). Ho alcuni dubbi:
1) chi garantisce l’inalterabilità del log tra il momento dell’invido dell’agent di windows al momento della masterizzazione?
2) Il garante se non mi sbagli menziona anche gli amministratori di DB, come vengono controllati? Io ad esempio ho sia DB MSSQL che MYSQL
Grazie.
Ciao Maido.
Nessuno garantisce il dato dalla generazione alla fase di conservazione. Il Garante stesso nelle FAQ e nel provvedimento scrive che non si intende richiedere di implementare un sistema rigoroso di controllo, cosa difficile soprattutto nei casi in cui controllato e controllore sono la stessa persona. La masterizzazione è il metodo più semplice per garantire l’inalterabilità del dato una volta registrato.
Tutti coloro che rientrano nella definizione di “Amministratore di sistema” (vale la pena di ricordare che AdS non equivale direttamente a “sistemista”) sono sottoposti alla medesima norma, ovvero registrazione degli accessi al sistema. In questo caso al DB. Trovi qualche spunto nei commenti del 18 dicembre a questo stesso articolo.
Buongiorno a tutti
complimenti per gli ottimi spunti.
Mi rimane però ancora qualche dubbio sui computer stand alone o quelle postazioni comunque non collegate ad un dominio o server; ho una situazione di questo tipo: in una sala ho 1 server connesso a 4 clients, e per questi non ho problemi. Ma sparsi in altri locali ho una ventina di computers stand alone che trattano dati personali. Intanto, come è possibile per ADS effettuare degli accessi logici su queste postazioni se non sono in rete?
Se i computers stand alone devono essere usati per le loro funzioni ordinarie con accounts diversi da quello di amministratore di sistema, in caso di accessi logici da parte di ADS come posso fare per la loro registrazione e conservazione? Ovviamente sarà possibile solo sul computer sul quale l’accesso è stato effettuato…
Grazie in anticipo
Ovviamente l’accesso di un AdS ad un computer stand alone sarà fatto dalla console dello stesso ed il Garante ha previsto questa fattispecie al punto 3 delle FAQ allegate al Provvedimento. L’obbligo di adempiere a quanto previsto dal provvedimento persiste anche nel caso di trattamenti di dati personali effettuati su un singolo personal computer e al punto 12 delle stesse FAQ sono anche suggerite le modalità tecniche “minime” per adempiere alle disposizioni relative alla raccolta ed inalterabilità dei log.
Un indirizzo email è un dato personale:
http://www.garanteprivacy.it/garante/doc.jsp?ID=29864
Bisogna registrare gli accessi degli ads anche ai db:
http://www.garanteprivacy.it/garante/doc.jsp?ID=1577499#19
Se su un db mysql ho un campo “email” devo registrare l’accesso dell’ads su un sistema di logging.
Abilitare il logging su mysql comporta scrivere su un file di log tutte le query/login/logoff/ecc (debug mode) e nota bene:
“Be aware that this log type is a performance killer.”
E’ corretto quello che dico ?
Corretto.
Corretto.
No.
Se su un db esistono “dati personali” devo loggare gli accessi degli amministratori al db. A prescindere se si tratti di indirizzi email od altro.
OK, quindi se su un db esistono dati personali (tra cui ad esempio il campo email) io devo loggare gli accessi degli ads al db. Bene.
L’unico modo che io conosco su mysql è quello di abilitare il logging completo di tutte le query fatte
che però ha il difetto di “uccidere” il server perchè troppo oneroso in termini di risorse occupate.
Mi potete suggerire una soluzione o devo abbandonare mysql ? 🙂
Grazie !!!
Per abilitare un log su MySQL puoi provare con le soluzioni suggerite in questo post di Maurizio Proietti:
http://tinyurl.com/ylgplsc
Grazie, ora guardo !!! 🙂
Il risultato si raggiunge ma come temevo… il server poi muore a meno che non si sia disposti ad avere dei costi in più.
Diciamo che mysql e garante della privacy non sono compatibili…
Ok, vediamo se fra tutti riusciamo a raggiungere un risultato migliore…
Butto la’ una idea che ho provato al volo e in prima battuta funziona pure.
L’idea è che avendo un utente di sistema abilitato esclusivamente ad accedere a mysql, sarà sufficiente loggare login e logout di questo utente, cosa semplice se per fare login con questo utente si utilizza sudo.
Ecco cosa ho fatto.
Ho creato un utente mysqlusr specificatamente per usare solo mysql.
ho creato un alias “msql” con il comando “sudo mysqlusr -c ‘mysql -u root -p'”
Lanciando il comando “msql” il sistema chiede prima la mia pwd per accedere al comando “sudo” e poi la pwd dell’utente mysql richiesto (root in questo esempio). Così accedo al prompt di mysql.
Nell’auth.log risulta che mi sono loggato con mysqlusr e quindi sono entrato su mysql. Viene loggata anche l’uscita.
E’ una cosa ancora grezza, ma forse potrebbe funzionare.
Qualcuno ha voglia di provare e farci sapere come va?
Andrebbe sperimentata e codificata e andrebbe visto se vi sono controindicazioni di qualche tipo.
A voi 🙂
E cosa vieta ad un utente “normale” di loggarsi con:
mysql -u root -p
?
Più che altro non mi è chiaro questo:
“Ho creato un utente mysqlusr specificatamente per usare solo mysql.”
In realtà sto pensando a fare una patch per mysql versione italiota che preveda un sistema di logging specifico per certe utenze e con una facility apposita (solo Connect e Quit).
Penso sia la soluzione più efficace, se vi va poi vi passo il tutto e mi fate anche da betatester 😉
Premetto che ci sto ragionando ora “in tempo reale”, pertanto potrebbero esserci dozzine di controindicazioni o problemi che impediscono il funzionamento del sistema.
Comunque ho modificato i permessi di esecuzione di /usr/bin/mysql così che possa essere eseguito solo dall’utente “mysqlusr”.
Mettendo nel bashrc di mysqlusr la chiamata al client mysql
/usr/bin/mysql -u root -p
exit
si arriva al prompt del db direttamente con: “sudo su mysqlusr” e si torna alla propria shell uscendo.
Ovviamente si deve gestire sudoers per dare il permesso di eseguire “sudo” solo agli AdS.
Bene, tienici informati.
“Comunque ho modificato i permessi di esecuzione di /usr/bin/mysql”
Con selinux ?
No, semplicemente modificando il proprietario ed i permessi del file eseguibile. Come dicevo è solo un test.
Il sistema di prova inoltre prevede questa configurazione: nessun utente si logga da terminale (shell impostate a /bin/false) ad esclusione degli AdS, root è disabilitato e solo gli AdS possono utilizzare sudo.
Sto sviluppando un’applicazione che gestirà un database con dati sensibili. Questa applicazione sarà ceduta a titolo gratuito ad una piccola organizzazione governativa estera, ma i dati risiederanno in Italia, sui miei server. Si configura la necessità di registrare i logs?
Ottimo blog, vera scienza.
Grazie
Da quanto ho capito, si configura quanto previsto dal Garante nelle FAQ al punto 23:
Ciao Paolo,
ti ringrazio per l’articolo molto interessante.
Mi sorge però un dubbio: come faccio a discriminare gli accessi dei soli amministratori di sistema ? Se l’utente “pippo” effettua un login sulla macchina linux “host”, nel log centralizzato vedo che l’utente “pippo” ha effettuato un accesso alla macchina “host”, ma nulla mi dice se “pippo” è un amministratore di quella macchina.
In effetti un sistema del genere registra tutti i login, quindi anche quelli di chi amministratore non è. La cosa è stata presa in considerazione anche nel provvedimento del Garante, dove si legge nella risposta alla FAQ n.10:
.
Quindi è sufficiente estrarre solo i dati relativi agli AdS con un filtro impostabile sul sistema utilizzato per l’analisi dei dati.
Ti ringrazio per la risposta chiarificatrice. A questo punto, per estrarre i dati relativi agli AdS con un filtro, dovrei sapere quali sono gli identificativi degli utenti amministrativi sulle varie macchine. Si possono memorizzare in una tabella di un db, o in file, e poi con uno script filtrare dai log solo quelli presenti in tabella.
Salve,
ho bisogno di copiare automaticamente i syslog in un db mysql..qualche idea??
Se vuoi registrare direttamente i log su mySql basta utilizzare un demone syslog che lo permetta come syslog-ng.
Trovi molti esempi su vari siti, ad esempio: http://openskill.info/infobox.php?ID=1466.
Se invece vuoi importare su un DB i dati precedentemente registrati su file di testo, dovrai lavorare un po di piu’ ma è fattibile. Cerca ad esempio “mysql import text file”.
Salve, qualcuno ha provato LOG196 il programma gratuito?
http://www.log196.com/Log196/LOG196.html
mi sembra una buona alternativa gratuita e semplice…che ne dite?