Logging su MySQL: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
mNessun oggetto della modifica
m (rimossa dalle adozioni, aggiunta Wheezy tra le supportate (vedere discussione))
 
(12 versioni intermedie di 7 utenti non mostrate)
Riga 1: Riga 1:
{{stub}}
{{Versioni compatibili|Lenny|Squeeze|Wheezy}}


Uno dei primi passi da affrontare subito l' installazione della nostra Debian dovrebbe essere quello di accertarsi di quali servizi e demoni vengono lanciati dal sistema. Questa operazione permette un controllo migliore della sicurezza della nostra macchina ed una minore esposizione a rischi legati a intrusioni.
{{Box| Per Wheezy e successive | A partire da Debian 7 ([[Wheezy]]) è possibile installare il pacchetto '''syslog-ng-mod-sql'''.}}


In questa breve guida vedremo come controllare i servizi attivi, come eliminare quelli non necessari e come rendere pi� sicuri quelli che intendiamo utilizzare.
== Premessa ==
Questa piccola guida, in questa sua prima versione, descrive velocemente la procedura per abilitare il logging di sistema su di un database MySQL. Essendo questo un compito di indirizzo prettamente professionale, non mi sono soffermato più di tanto nello spiegare i dettagli della procedura. Tantomeno ho elencato nel dettaglio '''tutti''' i comandi necessari, presumendo che chi legge abbia le competenze necessarie a completare le mie eventuali lacune. Qualsiasi commento o correzione è il benvenuto e sarà integrato in eventuali riscritture di questa guida che, in questa stesura, è poco più della traccia da me seguita in diverse occasione per realizzare quanto spiegato.


Buona lettura & happy debian!
Buona lettura e happy hacking!


=Concetti di base=
== Logging su MySQL ==
==Servizi & Demoni==
Spesso, specie in ambiente professionale, si ha la necessità di memorizzare i log di sistema in una località centralizzata vuoi per motivi di sicurezza che di semplice monitoraggio. Syslogd permette di implementare in maniera banale questa possibilità, ma a volte ci si trova nella necessità/desiderio di voler dare a questi log una forma facilmente gestibile e interrogabile come ad esempio un database MySQL.
In un sistema operativo si definisce "servizio" (o anche "demone") un processo in background che gira autonomamente, senza intervento da parte dell' utente, o comunque con una interazione ridotta al minimo. Un esempio di servizo è il server web Apache: il server viene controllato dal demone "httpd" che gira in background, resta in ascolto sulla porta indicata e serve le pagine richieste.
Esiste un syslogger che fa questo per noi, si tratta di syslogd-ng, però non sempre è possibile sostituire il logger in maniera indolore e trasparente.
In tutte queste situazioni viene in nostro aiuto una piccola utility : sqlsyslogd, realizzata da [mailto:venglin@freebsd.lublin.pl Przemyslaw Frasunek].


=Strumenti=
Sqlsyslogd è un wrapper per syslogd scritto in C per FreeBSD, ma è comunque compatibile con qualsiasi piattaforma POSIX e ANSI-C compliant (chi scrive non ha mai avuto problemi nell'usarlo su piattaforma GNU/Linux, in particolare Debian).
GNU/Linux fornisce una nutrita schiera di programmi che ci permettono di intergire con i servizi attivi sulla nostra macchina. Di seguito riporto quelli pi� usati nell' amministrazione di un sistema Debian.


==netstat==
Andiamo con ordine.


Netstat � uno dei programmi pi� utilizzati ed utili: permette di elencare tutta una serie di informazioni utili (sockets aperti, routing tables, processi, ecc...). Per il nostro scopo utilizzeremo netstat per ottenere un elenco di tutte le connessioni di rete aperte sulla nostra macchina. Ottenere queste informazioni � il primo passo per conoscere nel dettaglio cosa succede all' interno del nostro sistema operativo.  
=== Ottenere i sorgenti ===
Procuriamoci il sorgente all'indirizzo: [http://www.frasunek.com/sources/security/sqlsyslogd/sqlsyslogd.c sqlsyslogd.c]. Procuriamoci anche il [http://www.frasunek.com/sources/security/sqlsyslogd/Makefile MakeFile] e lo script che useremo per creare il nostro database: [http://www.frasunek.com/sources/security/sqlsyslogd/sqlsyslogd.sql sqlsyslogd.sql]


Ora cerchiamo tutte le connessioni di rete in ascolto (stato LISTEN) sul nostro sistema.
=== Compilazione del logger ===
Una volta ottenuto il sorgente del file compiliamolo digitando semplicemente:
<pre>
$ make
</pre>
nella directory in cui abbiamo scaricato i nostri file.<br>
Ora copiamo l'eseguibile creato in <code>/usr/local/sbin</code> (ad esempio):
<pre>
$ su
Password:
# cp sqlsyslogd /usr/local/sbin/
</pre>


<pre># netstat -l |grep tcp
=== Creare il database ===
tcp        0      0 *:netbios-ssn          *:*                    LISTEN
Creiamo il database con il comando:
tcp        0      0 *:5900                  *:*                    LISTEN
<pre>
tcp        0      0 *:www                  *:*                    LISTEN
$ mysql -u root -p < sqlsyslogd.sql
tcp        0      0 *:sieve                *:*                    LISTEN
</pre>
tcp        0      0 *:ssh                  *:*                    LISTEN
questo comando crea il database sqlsyslogd, che contiene l'unica tabella dei log.
tcp        0      0 localhost.localdom:8118 *:*                    LISTEN
tcp        0      0 *:ipp                  *:*                    LISTEN
tcp        0      0 localhost.localdom:smtp *:*                    LISTEN
tcp        0      0 *:microsoft-ds          *:*                    LISTEN</pre>


Ho scelto di limitare l' output alle sole connessioni in attesa di connessione. Potete anche provare ad utilizzare i comandi '''netstat -a''', '''netstat -l''', '''netstat -l |grep tcp''', ecc...
Fermiamoci un momento a spiegare il funzionamento del wrapper: sqlsyslogd è un programma C che "intercetta" le chiamate di syslogd e le redirige verso una pipe. Dato che il syslogger syslogd non può puntare direttamente ad un altro programma (come invece può fare il suo cugino di FreeBSD), ma soltanto ad una named pipe, abbiamo bisogno di un ulteriore passaggio.


Le colonne da prendere in esame sono (in questo esempio) la terza e la quarta. La terza colonna riporta l' accoppiata indirizzo+porta su cui � un ascolto il servizio.  
=== Il Wrapper ===
Scarichiamo questo [http://www.frasunek.com/sources/security/sqlsyslogd/contrib/sqlsyslogd-on-redhat-7.3 script perl] e rinominiamolo ad esempio in "sqlsyslogd.wrapper".<br>
Questo script crea per noi un FIFO socket. Syslogd manderà i suoi messaggi al socket, e il wrapper li inoltrerà a sqlsyslogd.


Se osserviamo la prima linea dell' output, la terza colonna indica come coppia indirizzo+porta il testo '''*:netbios-ssn''': questo significa che � attivo un servizio in ascolto per qualsiasi (*) indirizzo di rete configurato sulla macchina e che questo servizio � associato alla porta '''netbios-ssn'''.
== Configurazione ==
Creaimo il file <code>/usr/local/etc/sqlsyslogd.conf</code> e come unica riga, digitiamo la password necessaria a poter scrivere nel nostro database. Dato che sqlsyslogd gira con le credenziali dell'utente che lo lancia e che - presumibilmente - vorremo avviarlo al boot della nostra macchina, potremo creare un utente apposito o più semplicemente usare le credenziali dell'utente "root". In questo caso in <code>sqlsyslogd.conf</code> inseriremo la password di root (occhio ai permessi su questo file!).


Nelle altre righe possiamo notare che, nella colonna degli indirizzi, oltre al "*" (che indica ''qualsiasi indirizzo'') compare anche ''localhost.localdomain''. Netstat tenta di risolvere gli indirizzi ip e reperisce questo hostname dal file '''/etc/hosts''', per cui localhost.localdomain corrisponde (nel mio esempio) all' indirizzo dell' interfaccia di loopback (127.0.0.1), come possiamo verificare con un semplice
Lo script perl permette di specificare sia il server che ospita il database, sia l'utente con con collegarsi.
Il mio suggerimento, rivolto a ovvie questioni di sicurezza, consiste nel creare un apposito utente con cui far girare il wrapper e con cui accedere al database!!


<pre>$ cat /etc/hosts |grep localhost.localdomain
Editiamo il file <code>sqlsyslogd.wrapper</code> e adattiamolo alla nostra configurazione e alle nostre esigenze.
127.0.0.1 localhost.localdomain localhost debby</pre>


&Egrave; interessante notare come per alcune porte venga riportato un valore numerico, mentre per altre un valore alfanumerico.
Editiamo <code>/etc/syslogd.conf</code> e scriviamo una riga del tipo:
<pre>
*.* |/path/to/sqlsyslogd.wrapper
</pre>
Possiamo specificare tutte le facilities che vogliamo e loggare soltanto quello che ci interessa. La direttiva dell'esempio redirige tutto quello che viene loggato.


Valore numerico:
Assicuriamoci che sqlsyslogd e sqlsyslogd.wrapper vengano lanciati ad ogni riavvio della macchina, aggiungendoli ad esempio ad uno script di avvio.
<pre>tcp        0      0 *:5900                  *:*                    LISTEN</pre>
Valore alfanumerico:
<pre>tcp        0      0 *:netbios-ssn          *:*                    LISTEN</pre>


Questo comportamento di netstat � presto spiegato: quando il programma rileva un servizio in ascolto su una porta (ad esempio la porta 5900), cerca una corrispondenza con la stessa all' interno del file ''/etc/services''.
== Conclusioni ==
Finalmente possiamo riavviare syslogd e cominciare a importare in tempo reale i nostri log in MySQL!!
<pre>
# killall -HUP syslogd
</pre>
o anche:
<pre>
# /etc/init.d/sysklogd reload
</pre>


Il file ''services'' � un file testuale che associa un numero di porta numerico alla descrizione alfanumerica del servizio associato alla stessa.
{{Autori
|Autore = [[Utente: Keltik|Keltik]]
|Estesa_da =
|Verificata_da =
|Numero_revisori = 0
}}


Se vogliamo vedere a quale porta corrisponda il dato ''netbios-ssn'' dell' esempio precedente, sufficiente cercarlo all' interno del file services:


<pre>$ cat /etc/services |grep netbios-ssn
[[Categoria:Database server]]
netbios-ssn    139/tcp                        # NETBIOS session service
[[Categoria:Monitoraggio]]
netbios-ssn    139/udp</pre>
 
Nel nostro esempio, dato che la porta era di tipo TCP, il valore cercato � il primo ottenuto.
 
Agendo sul file services possiamo quindi assegnare un valore descrittivo alle porte riportate solo con il valore numerico. Ad esempio tornando alla porta 5900, probabilmente vorremo associarla al servizio ad essa associata (vnc).
 
Sar� quindi sufficiente editare il file services ed aggiungere la linea:
 
<pre>vnc-server      5900/tcp        vnc-server      # TightVNC Server</pre>
 
A questo punto avremo realizzato l' associazione porta/descrizione:
 
<pre>~# netstat -l |grep tcp
[...]
tcp        0      0 *:vnc-server            *:*                    LISTEN
[...]</pre>
 
Per quanto riguarda la quarta colonna, nell' esempio precedente possiamo vedere che il valore � identico per tutti i servizi e cio� '''*:*'''. Questo significa che il servizio � pronto a ricevere connessioni da qualsiasi indirizzo ip e da qualsiasi porta ad esso associata.
 
Notiamo a questo punto che alcuni dei servizi avviati sono in ascolto su qualsiasi indirizzo ip configurato sulla nostra macchina (*), mentre alcuni sono legati (si dice anche binding) all' indirizzo ''localhost.localdomain'' che abbiamo visto prima corrispondere all' indirizzo di loopback (127.0.0.1).
 
Quando un servizio � in ascolto unicamente sull' interfaccia di loopback significa che sar� raggiungibile unicamente attraverso quell' interfaccia. Questo ci garantisce che l'unico host in grado di contattare il servizio � la stessa macchina che lo ha in esecuzione.
 
Nell' esempio di prima i servizi raggiungibili unicamente dall' interfaccia di loopback sono '''smtp''' e '''8118'''. Come impareremo a verificare pi� tardi, si tratta rispettivamente del server di posta '''exim''' e del proxy '''privoxy'''.
 
==lsof==
 
Se con '''netstat''' siamo in grado di monitorare quali servizi sono in ascolto sulla nostra macchina, � anche indispensabile sapere quale programma abbia lanciato e controlli ogni singolo servizio.
 
Una caratteristica peculiare dei sistemi operativi derivati da Unix (tra cui appunto GNU/Linux) � che qualsiasi elemnto del sistema viene visto come se fosse un file. Abbiamo files veri e propri (ad es.: pippo.txt), abbiamo i dispositivi hardware (si trovano in /dev, e sono rappresentati da file veri e propri) ed abbiamo le connessioni di rete (anche queste sono veri e propri file).
 
Approfittando di questa caratteristica di GNU/Linux, possiamo investigare in maniera approfondita sui nostri servizi: se per il sistema operativo si tratta di files allora possiamo sapere chi li ha creati e chi li ha aperti.
 
Lo strumento principe per questo scopo � '''lsof'''. Come per la maggior parte dei comandi GNU, lsof � una abbreviazione (in questo caso ricorsiva!) della descrizione del comando: lsof = '''LS O'''pen '''F'''iles, cio� '''L'''i'''S'''t '''O'''pen '''F'''iles (elenca i files aperti).
 
Dato che le connessioni di rete sono rappresentate da veri e propri files, possiamo usare lsof per ottenere informazioni su di esse.
 
Poniamo il caso di voler ottenere informazioni sul servizio:
 
<pre>tcp        0      0 *:netbios-ssn          *:*                    LISTEN</pre>
 
Sar� sufficiente utilizzare lsof:
 
<pre># lsof -i |grep netbios-ssn
smbd      4089        root  21u  IPv4  8082      TCP *:netbios-ssn (LISTEN)</pre>
 
In questo modo possiamo vedere che il servizio in ascolto sulla porta associata a '''netbios-ssn''' (la porta 139) � controllato dal programma '''smbd'''.
 
Allo stesso modo possiamo fare con '''www''' e '''smtp''', ecc...
 
<pre># lsof -i |grep www
apache    4342        root  16u  IPv4  8423      TCP *:www (LISTEN)
apache    4349    www-data  16u  IPv4  8423      TCP *:www (LISTEN)
 
# lsof -i |grep smtp
exim4    3901 Debian-exim    3u  IPv4  7625      TCP localhost.localdomain:smtp (LISTEN)</pre>
 
==Apt System==
 
Ora che sappiamo quale programma controlla un determinato servizio, abbiamo la possibilit� di risalire a quale pacchetto Debian lo contiene per - eventualmente - rimuoverlo, oppure ottenere versioni pi� aggiornate, ricompilarlo con patches specifiche, ecc...
 
Il sistema pi� semplice ed allo stesso pi� potente per individuare quale pacchetto Debian contiene un file, consiste nell' utilizzare il programma '''apt-file'''. Per l' installazione e l' utilizzo di apt-file, vi rimando all' ottima guida [[Apt-file: ricerca all'interno dei pacchetti]], scritta da MaXeR.
 
Nel contesto a noi necessario utilizzeremo la funzione di ricerca di apt-file per risalire a quale pacchetto contiene il programma che lancia un particolare demone.
 
Continuiamo a utilizzare come esempio il servizio in ascolto sulla porta '''netbios-ssn'''. Per adesso siamo riusciti a risalire al fatto che il servizio netbios-ssn corrisponde alla porta 139 e che � controllato da '''smbd'''.
 
Ora vedremo cosa sia '''smbd'''. Prima di tutto verifichiamo quale script o programma si preoccupa di lanciare smbd
 
<pre># lsof |grep smbd |grep txt
smbd      4089        root  txt      REG        3,3  2805852      34840 /usr/sbin/smbd
smbd      4094        root  txt      REG        3,3  2805852      34840 /usr/sbin/smbd</pre>
 
 
Ora vediamo quale pacchetto contiene /usr/sbin/smbd:
 
<pre># apt-file search /usr/sbin/smbd
samba: usr/sbin/smbd
samba-dbg: usr/lib/debug/usr/sbin/smbd</pre>
 
Controlliamo quale di essi sia presente nel nostro sistema:
 
<pre># dpkg -l samba*
Desiderato=sconosciUto/Installato/Rimosso/P:eliminato/H:bloccato
| Stato=Non/Installato/file Config./U:spacchett./conf. Fallita/H:inst.parzial.
|/ Err?=(nessuno)/H:bloc./necess.Reinst./X=entrambi (Stato,Err: maiusc.=grave)
||/ Nome          Versione      Descrizione
+++-==============-==============-============================================
ii  samba          3.0.14a-6      a LanManager-like file and printer server fo
un  samba-client  <non definita> (descrizione non disponibile)
ii  samba-common  3.0.14a-6      Samba common files used by both the server a
un  samba-doc      <non definita> (descrizione non disponibile)</pre>
 
 
----
[[Utente:Keltik|Keltik]] 05:26, Giu 23, 2005 (EDT)
[[Categoria:Sistema]]
[[Categoria:Networking]]

Versione attuale delle 10:34, 30 nov 2015

Edit-clear-history.png Attenzione. Questa guida è da considerarsi abbandonata, per via del tempo trascorso dall'ultima verifica.

Potrà essere resa obsoleta, previa segnalazione sul forum, se nessuno si propone per l'adozione.


Debian-swirl.png Versioni Compatibili

Debian 5 "lenny"
Debian 6 "squeeze"
Debian 7 "wheezy"
Info.png Per Wheezy e successive
A partire da Debian 7 (Wheezy) è possibile installare il pacchetto syslog-ng-mod-sql.


Premessa

Questa piccola guida, in questa sua prima versione, descrive velocemente la procedura per abilitare il logging di sistema su di un database MySQL. Essendo questo un compito di indirizzo prettamente professionale, non mi sono soffermato più di tanto nello spiegare i dettagli della procedura. Tantomeno ho elencato nel dettaglio tutti i comandi necessari, presumendo che chi legge abbia le competenze necessarie a completare le mie eventuali lacune. Qualsiasi commento o correzione è il benvenuto e sarà integrato in eventuali riscritture di questa guida che, in questa stesura, è poco più della traccia da me seguita in diverse occasione per realizzare quanto spiegato.

Buona lettura e happy hacking!

Logging su MySQL

Spesso, specie in ambiente professionale, si ha la necessità di memorizzare i log di sistema in una località centralizzata vuoi per motivi di sicurezza che di semplice monitoraggio. Syslogd permette di implementare in maniera banale questa possibilità, ma a volte ci si trova nella necessità/desiderio di voler dare a questi log una forma facilmente gestibile e interrogabile come ad esempio un database MySQL. Esiste un syslogger che fa questo per noi, si tratta di syslogd-ng, però non sempre è possibile sostituire il logger in maniera indolore e trasparente. In tutte queste situazioni viene in nostro aiuto una piccola utility : sqlsyslogd, realizzata da Przemyslaw Frasunek.

Sqlsyslogd è un wrapper per syslogd scritto in C per FreeBSD, ma è comunque compatibile con qualsiasi piattaforma POSIX e ANSI-C compliant (chi scrive non ha mai avuto problemi nell'usarlo su piattaforma GNU/Linux, in particolare Debian).

Andiamo con ordine.

Ottenere i sorgenti

Procuriamoci il sorgente all'indirizzo: sqlsyslogd.c. Procuriamoci anche il MakeFile e lo script che useremo per creare il nostro database: sqlsyslogd.sql

Compilazione del logger

Una volta ottenuto il sorgente del file compiliamolo digitando semplicemente: 

$ make

nella directory in cui abbiamo scaricato i nostri file.
Ora copiamo l'eseguibile creato in /usr/local/sbin (ad esempio): 

$ su
Password:
# cp sqlsyslogd /usr/local/sbin/

Creare il database

Creiamo il database con il comando: 

$ mysql -u root -p < sqlsyslogd.sql

questo comando crea il database sqlsyslogd, che contiene l'unica tabella dei log.

Fermiamoci un momento a spiegare il funzionamento del wrapper: sqlsyslogd è un programma C che "intercetta" le chiamate di syslogd e le redirige verso una pipe. Dato che il syslogger syslogd non può puntare direttamente ad un altro programma (come invece può fare il suo cugino di FreeBSD), ma soltanto ad una named pipe, abbiamo bisogno di un ulteriore passaggio.

Il Wrapper

Scarichiamo questo script perl e rinominiamolo ad esempio in "sqlsyslogd.wrapper".
Questo script crea per noi un FIFO socket. Syslogd manderà i suoi messaggi al socket, e il wrapper li inoltrerà a sqlsyslogd.

Configurazione

Creaimo il file /usr/local/etc/sqlsyslogd.conf e come unica riga, digitiamo la password necessaria a poter scrivere nel nostro database. Dato che sqlsyslogd gira con le credenziali dell'utente che lo lancia e che - presumibilmente - vorremo avviarlo al boot della nostra macchina, potremo creare un utente apposito o più semplicemente usare le credenziali dell'utente "root". In questo caso in sqlsyslogd.conf inseriremo la password di root (occhio ai permessi su questo file!).

Lo script perl permette di specificare sia il server che ospita il database, sia l'utente con con collegarsi. Il mio suggerimento, rivolto a ovvie questioni di sicurezza, consiste nel creare un apposito utente con cui far girare il wrapper e con cui accedere al database!!

Editiamo il file sqlsyslogd.wrapper e adattiamolo alla nostra configurazione e alle nostre esigenze.

Editiamo /etc/syslogd.conf e scriviamo una riga del tipo: 

*.* |/path/to/sqlsyslogd.wrapper

Possiamo specificare tutte le facilities che vogliamo e loggare soltanto quello che ci interessa. La direttiva dell'esempio redirige tutto quello che viene loggato.

Assicuriamoci che sqlsyslogd e sqlsyslogd.wrapper vengano lanciati ad ogni riavvio della macchina, aggiungendoli ad esempio ad uno script di avvio.

Conclusioni

Finalmente possiamo riavviare syslogd e cominciare a importare in tempo reale i nostri log in MySQL!! 

# killall -HUP syslogd

o anche: 

# /etc/init.d/sysklogd reload



Guida scritta da: Keltik Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

Verificare ed estendere la guida | Cos'è una guida Debianized

Estratto da "https://guide.debianizzati.org/index.php?title=Logging_su_MySQL&oldid=40327"