Debian e il controllo di servizi e demoni: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
m (→‎netstat: typos)
m (→‎Apt System: mancate virgolette (errore su zsh o con impostazione non default di bash))
 
(24 versioni intermedie di 7 utenti non mostrate)
Riga 1: Riga 1:
In questa guida vedremo come configurare la connessione tra la nostra Debian box ed un cellulare Nokia 7210.
{{Versioni compatibili}}
== Introduzione ==
Uno dei primi passi da affrontare subito dopo l'installazione della nostra Debian dovrebbe essere quello di accertarsi quali sono i servizi e i demoni che vengono lanciati dal sistema. Questa operazione permette un controllo migliore della sicurezza della nostra macchina ed una minore esposizione a rischi legati ad intrusioni.


Alcune doverose precisazioni:
In questa breve guida vedremo come controllare i servizi attivi, come eliminare quelli non necessari e come rendere più sicuri quelli che intendiamo utilizzare.
* il kernel utilizzato � un vanilla 2.6.13.4, ma vedremo i moduli necessari in modo da poter adattare la guida ad altre versioni;
* il cavo di collegamento USB utilizzato � un '''BeKonnekt BKPIKMM7250''', commercializzato da CellularLine al prezzo di circa 30 euro. Non viene indicata la sua compatibilit� con GNU/Linux e tantomeno viene fornito supporto agli utenti: vedremo come farla in barba al closed-source e goderci il nostro cellulare;
* il software utilizzato � gnokii, versione 0.6.9 pacchettizzato Debian (repository di testing).


''Guida segnalata su [http://tuxmobil.org/phones_survey_nokia.html TuxMobil]''
Buona lettura & happy Debian!


=Operazioni preliminari=
== Concetti di base ==
==Configurazione del kernel==
=== Servizi & Demoni ===
Il cavo USB che mette in comunicazione PC e cellulare � dotato di un chip che converte il segnale proveniente dal telefono e lo invia sulla porta USB emulando una connessione seriale.
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 servizio è 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.


Da console � facilmente individuabile quale sia il chip utilizzato:
== Strumenti ==
<pre>$ lsusb
GNU/Linux fornisce una nutrita schiera di programmi che ci permettono di interagire con i servizi attivi sulla nostra macchina. Di seguito riporto quelli più usati nell'amministrazione di un sistema Debian.
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 002 Device 002: ID 04b3:310b IBM Corp. Red Wheel Mouse
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000</pre>
possiamo vedere che il device 003 sul bus 002 corrisponde ad una porta seriale e che il chip � il PL2303 di Prolific Technology. Si tratta di un chip supportato dal kernel linux: tutto quello che dobbiamo fare consiste nell' abilitare almeno come moduli il supporto generico alle connessioni seriali USB e quello specifico per il chip in nostro possesso.


Le voci da abilitare (le trovate nella sezione Device Drivers/USB) sono:
=== netstat ===


<pre>CONFIG_USB_SERIAL=m
''Netstat'' è uno dei programmi più utili ed utilizzati: permette di elencare tutta una serie di informazioni utili (socket 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.  
CONFIG_USB_SERIAL_PL2303=m</pre>
Controllate se il vostro kernel � gi� configurato per l' utilizzo di questi moduli:
<pre>$ cat /usr/src/linux/.config |grep CONFIG_USB_SERIAL</pre>


se cos� non fosse dovete abilitarli e ricompilare il kernel.
Ora cerchiamo tutte le connessioni di rete in ascolto (stato <code>LISTEN</code>) sul nostro sistema.


Fatto questo riavviate e proseguiamo.
<pre># netstat -l |grep tcp
tcp        0      0 *:netbios-ssn          *:*                    LISTEN
tcp        0      0 *:5900                  *:*                    LISTEN
tcp        0      0 *:www                  *:*                    LISTEN
tcp        0      0 *:sieve                *:*                    LISTEN
tcp        0      0 *:ssh                  *:*                    LISTEN
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>


==Verifica del collegamento==
Ho scelto di limitare l'output alle sole connessioni in attesa di connessione. Potete anche provare ad utilizzare i comandi <code>'''netstat -a'''</code>, <code>'''netstat -l'''</code>, <code>'''netstat -l |grep tcp'''</code>, ecc.
Una volta preparato il kernel, verifichiamo che esso rilevi correttamente il cavetto USB.


Apriamo una console e logghiamoci come utente '''root''', in modo da poter controllare i messaggi inviati dal sistema:
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 è in ascolto il servizio.


<pre># tail -f /var/log/messages</pre>
Se osserviamo la prima linea dell'output, la terza colonna indica come coppia indirizzo+porta il testo <code>'''*:netbios-ssn'''</code>: questo significa che è attivo un servizio in ascolto per qualsiasi (<code>*</code>) indirizzo di rete configurato sulla macchina e che questo servizio è associato alla porta <code>'''netbios-ssn'''</code>.


Ora colleghiamo il cavello ad una presa USB, dovremmo osservare qualcosa di questo tipo:
Nelle altre righe possiamo notare che, nella colonna degli indirizzi, oltre al <code>*</code> (che indica ''qualsiasi indirizzo'') compare anche <code>''localhost.localdomain''</code>. ''Netstat'' tenta di risolvere gli indirizzi IP e reperisce questo hostname dal file <code>/etc/hosts</code>, per cui <code>''localhost.localdomain''</code> corrisponde (nel mio esempio) all'indirizzo dell'interfaccia di loopback (127.0.0.1), come possiamo verificare con un semplice:


<pre>Oct 30 20:12:55 localhost kernel: usb 2-2: new full speed USB device using uhci_hcd and address 4
<pre>$ cat /etc/hosts |grep localhost.localdomain
Oct 30 20:12:55 localhost kernel: usbcore: registered new driver usbserial
127.0.0.1 localhost.localdomain localhost debby</pre>
Oct 30 20:12:55 localhost kernel: drivers/usb/serial/usb-serial.c: USB Serial Driver core v2.0
Oct 30 20:12:55 localhost kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for PL-2303
Oct 30 20:12:55 localhost kernel: pl2303 2-2:1.0: PL-2303 converter detected
Oct 30 20:12:55 localhost kernel: usb 2-2: PL-2303 converter now attached to ttyUSB0
Oct 30 20:12:55 localhost kernel: usbcore: registered new driver pl2303
Oct 30 20:12:55 localhost kernel: drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver v0.12
Oct 30 20:12:55 localhost usb.agent[6999]:      pl2303: loaded successfully</pre>


Notiamo che viene rilevata una nuova periferica USB seriale e che per essa viene caricato il driver pl2303, relativo al chip del nostro cavetto. La cosa pi� importate consiste nell' identificare quale porta seriale viene assegnata al dispositivo, perch� ci sar� necessaria in seguito. In qusto caso la porta � la '''ttyUSB0'''.
È interessante notare come per alcune porte venga riportato un valore numerico, mentre per altre un valore alfanumerico.


=Utilizzo di gnokii=
Valore numerico:
<pre>tcp        0      0 *:5900                  *:*                    LISTEN</pre>
Valore alfanumerico:
<pre>tcp        0      0 *:netbios-ssn          *:*                    LISTEN</pre>


La comunit� del software libero ha sviluppato un ottimo programma per interagire con il nostro cellulare, che non ci far� rimpiangere la Nokia Data Suite. Si tratta di [http://www.gnokii.org Gnokii], disponibile anche come pacchetto Debian.
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 <code>/etc/services</code>.


==Installare Gnokii==
Il file <code>/etc/services</code> è un file testuale che associa un numero di porta numerico alla descrizione alfanumerica del servizio associato alla stessa.


Prima di tutto installiamo Gnokii:
Se vogliamo vedere a quale porta corrisponda il dato <code>''netbios-ssn''</code> dell'esempio precedente, è sufficiente cercarlo all'interno del file <code>/etc/services</code>:


<pre># apt-get install gnokii
<pre>$ cat /etc/services |grep netbios-ssn
Lettura della lista dei pacchetti in corso... Fatto
netbios-ssn    139/tcp                        # NETBIOS session service
Generazione dell'albero delle dipendenze in corso... Fatto
netbios-ssn    139/udp</pre>
I seguenti pacchetti verranno inoltre installati:
  libgnokii2
I seguenti pacchetti NUOVI (NEW) saranno installati:
  gnokii libgnokii2</pre>
confermiamo l' installazione e proseguiamo.


==Configurare Gnokii==
Nel nostro esempio, dato che la porta era di tipo TCP, il valore cercato è il primo ottenuto.


Gnokii necessita di essere configurato prima che sia possibile utilizzarlo. Questa operazione va fatta attraverso la creazione del file ''.gnokiirc'' all' interno della nostra home:
Agendo sul file <code>/etc/services</code> 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).


<pre>$ touch .gnokiirc</pre>
Sarà quindi sufficiente editare il file <code>/etc/services</code> ed aggiungere la linea:


Ora dobbiamo compilare il file appena creato. Il pacchetto gnokii fornisce alcuni files di esempio. Di seguito ecco cosa inserire all' interno di gnokiirc per il nostro Nokia 7210:
<pre>vnc-server      5900/tcp        vnc-server      # TightVNC Server</pre>


<pre>[global]
A questo punto avremo realizzato l'associazione porta/descrizione:
port = /dev/ttyUSB0
model =6510
initlength = default
connection = serial
use_locking = yes
serial_baudrate = 19200
smsc_timeout = 10
[gnokiid]
bindir = /usr/local/sbin/
[connect_script]
TELEPHONE = 12345678
[disconnect_script]
[logging]
debug = on
rlpdebug = off
xdebug = off</pre>


Gli elementi pi� interessanti del file sono sicuramente
<pre># netstat -l |grep tcp
; port = ''che corrisponde alla porta creata dal driver subserial''.
[...]
; model = ''che indica quale driver utilizzare per il cellulare. 6510 � quello indicato per il nostro 7210''.
tcp        0      0 *:vnc-server            *:*                    LISTEN
; connection = ''che indica il tipo di cavo utilizzato''.
[...]</pre>


&Egrave; necessario che il device ttyUSB0 sia leggibile e scrivibile da parte del nostro utente. Usbserial crea il dispositivo assegnando i permessi di lettura e scrittura all' utente root ed al gruppo dialout, come possiamo vedere con un ''ls'':
Per quanto riguarda la quarta colonna, nell'esempio precedente possiamo vedere che il valore è identico per tutti i servizi e cioè <code>'''*:*'''</code>. Questo significa che il servizio è pronto a ricevere connessioni da qualsiasi indirizzo IP e da qualsiasi porta ad esso associata.


<pre>$ ls -l /dev |grep ttyUSB0
Notiamo a questo punto che alcuni dei servizi avviati sono in ascolto su qualsiasi indirizzo IP configurato sulla nostra macchina (<code>*</code>), mentre alcuni sono legati (si dice anche ''binding'') all'indirizzo <code>''localhost.localdomain''</code> che abbiamo visto prima corrispondere all'indirizzo di loopback (127.0.0.1).
crw-rw----  1 root dialout 188,   0 2005-10-30 20:12 ttyUSB0</pre>


Se non siamo che il nostro utente appartenga al gruppo dialout, � sufficiente inserirlo:
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.


<pre># adduser nome_utente dialout</pre>
Nell'esempio di prima, i servizi raggiungibili unicamente dall'interfaccia di loopback sono <code>'''smtp'''</code> e <code>'''8118'''</code>. Come impareremo a verificare più tardi, si tratta rispettivamente del server di posta <code>'''exim'''</code> e del proxy <code>'''privoxy'''</code>.


==Verifica della configurazione==
=== lsof ===


Per verificare che il sistema sia effettivamente in grado di comunicare con il cellulare utilizziamo questa procedura:
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.


<pre>$ gnokii --identify
Una caratteristica peculiare dei sistemi operativi derivati da Unix (tra i quali appunto GNU/Linux) è che qualsiasi elemento del sistema viene visto come se fosse un file. Abbiamo file veri e propri (ad es.: <code>pippo.txt</code>), abbiamo dispositivi hardware (si trovano in <code>/dev</code> e sono rappresentati da file veri e propri) ed abbiamo le connessioni di rete (anche queste sono veri e propri file).
GNOKII Version 0.6.9
LOG: debug mask is 0x1
phone instance config:
model: 6510
port_device: /dev/ttyUSB0
connection_type: 2
init_length: 0
serial_baudrate: 19200
serial_write_usleep: -1
hardware_handshake: 0
require_dcd: 0
smsc_timeout: 100
connect_script:
disconnect_script:
rfcomm_cn: 1
sm_retry: off
Connecting
Serial device: opening device /dev/ttyUSB0
Serial device: setting RTS to low and DTR to low
Serial device: setting RTS to high and DTR to high
Serial device: setting speed to 19200
Serial device: setting speed to 115200
Getting model...
Message sent: 0x1b / 0x0006
00 01 00 07 01 00                              |
[Received Ack of type 1b, seq: 80]
[Sending Ack of type 1b, seq: 4]
Message received: 0x1b / 0x002e
01 31 00 08 00 01 58 28 00 23 56 20 35 2e 35 32 |  1    X( #V 5.52
0a 31 39 2d 30 39 2d 30 33 0a 4e 48 4c 2d 34 0a |  19-09-03 NHL-4
28 63 29 20 4e 6f 6b 69 61 2e 0a 43 00 00      | (c) Nokia. C
Received message type 1b
model length: 5
Received model NHL-4
Identifying...
Message sent: 0x1b / 0x0005
00 01 00 00 41                                  |    A
Message sent: 0x1b / 0x0006
00 01 00 07 01 00                              |
[Received Ack of type 1b, seq:  1]
[Received Ack of type 1b, seq:  2]
[Sending Ack of type 1b, seq: 5]
Message received: 0x1b / 0x001a
01 31 00 01 00 01 41 14 00 10 33 35 32 35 32 32 |  1    A  352522
30 30 33 32 38 34 37 31 35 00                  | 003284715
Received message type 1b
Received imei 352522003284715
[Sending Ack of type 1b, seq: 6]
Message received: 0x1b / 0x002e
01 31 00 08 00 01 58 28 00 23 56 20 35 2e 35 32 |  1    X( #V 5.52
0a 31 39 2d 30 39 2d 30 33 0a 4e 48 4c 2d 34 0a |  19-09-03 NHL-4
28 63 29 20 4e 6f 6b 69 61 2e 0a 43 00 00      | (c) Nokia. C
Received message type 1b
Received revision V 5.52
model length: 5
Received model NHL-4
IMEI        : 352522003284715
Manufacturer : Nokia
Model        : NHL-4
Revision    : V 5.52
Serial device: closing device</pre>


Possiamo vedere come il collegamento sia effettivamente attivo.
Approfittando di questa caratteristica di GNU/Linux, possiamo investigare in maniera approfondita sui nostri servizi: se per il sistema operativo si tratta di file allora possiamo sapere chi li ha creati e chi li ha aperti.


==Uso di Gnokii==
Lo strumento principe per questo scopo è '''lsof'''. Come per la maggior parte dei comandi GNU, ''lsof'' è una abbreviazione della descrizione del comando: lsof = '''LS O'''pen '''F'''iles, cioè '''L'''i'''S'''t '''O'''pen '''F'''iles (elenca i file aperti).


Il pacchetto Gnokii fornisce una serie di programmi, il pi� utile dei quali � senzaltro '''xgnokii''', che ci permette di interagire in modo intuitivo e tramite interfaccia grafica con il nostro cellulare.
Dato che le connessioni di rete sono rappresentate da veri e propri file, possiamo usare ''lsof'' per ottenere informazioni su di esse.


Lanciando xgnokii da console, o utilizzando la voce ad esso relativa presente nel menu, potremo importare, esportare e fare il backup della nostra rubrica, agenda, calendario, messaggi. Potremo anche comporre messaggi SMS e inviarli ad uno o pi� numeri telefonici presenti in rubrica o inseriti manualmente, leggere i messaggi ricevuti, ecc...
Poniamo il caso di voler ottenere informazioni sul servizio:


Ecco alcuni screenshots di xgnokii in azione sul mio portatile.
<pre>tcp        0      0 *:netbios-ssn          *:*                    LISTEN</pre>


[[Immagine:Interfaccia.png|thumb|left|Interfaccia principale di xgnokii]]
Sarà sufficiente utilizzare ''lsof'':
[[Immagine:Calendario.png|thumb|left|Gestione del calendario di xgnokii]]
 
[[Immagine:Messaggi.png|thumb|left|Gestione dei messaggi di xgnokii]]
<pre># lsof -i |grep netbios-ssn
[[Immagine:Rubrica.png|thumb|left|Gestione della rubrica di xgnokii]]
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 <code>'''netbios-ssn'''</code> (la porta 139) è controllato dal programma <code>'''smbd'''</code>.
 
Allo stesso modo possiamo fare con <code>'''www'''</code> e <code>'''smtp'''</code>, 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 patch 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 ad utilizzare come esempio il servizio in ascolto sulla porta <code>'''netbios-ssn'''</code>. Per adesso siamo riusciti a risalire al fatto che il servizio <code>''netbios-ssn''</code> corrisponde alla porta 139 e che è controllato da <code>'''smbd'''</code>.
 
Ora vedremo cosa sia <code>'''smbd'''</code>. 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 <code>/usr/sbin/smbd</code>:
 
<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>
 
{{Autori
|Autore = [[Utente:Keltik|Keltik]] 05:26, Giu 23, 2005 (EDT)
}}
 
[[Categoria:Ottimizzazione del sistema]]
[[Categoria:Apt]]
[[Categoria:Monitoraggio]]

Versione attuale delle 14:22, 2 apr 2015

Debian-swirl.png Versioni Compatibili

Tutte le versioni supportate di Debian

Introduzione

Uno dei primi passi da affrontare subito dopo l'installazione della nostra Debian dovrebbe essere quello di accertarsi quali sono i servizi e i demoni che vengono lanciati dal sistema. Questa operazione permette un controllo migliore della sicurezza della nostra macchina ed una minore esposizione a rischi legati ad intrusioni.

In questa breve guida vedremo come controllare i servizi attivi, come eliminare quelli non necessari e come rendere più sicuri quelli che intendiamo utilizzare.

Buona lettura & happy Debian!

Concetti di base

Servizi & Demoni

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 servizio è 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.

Strumenti

GNU/Linux fornisce una nutrita schiera di programmi che ci permettono di interagire con i servizi attivi sulla nostra macchina. Di seguito riporto quelli più usati nell'amministrazione di un sistema Debian.

netstat

Netstat è uno dei programmi più utili ed utilizzati: permette di elencare tutta una serie di informazioni utili (socket 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.

Ora cerchiamo tutte le connessioni di rete in ascolto (stato LISTEN) sul nostro sistema.

# netstat -l |grep tcp
tcp        0      0 *:netbios-ssn           *:*                     LISTEN
tcp        0      0 *:5900                  *:*                     LISTEN
tcp        0      0 *:www                   *:*                     LISTEN
tcp        0      0 *:sieve                 *:*                     LISTEN
tcp        0      0 *:ssh                   *:*                     LISTEN
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

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.

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 è in ascolto il servizio.

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.

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:

$ cat /etc/hosts |grep localhost.localdomain
127.0.0.1 localhost.localdomain localhost debby

È interessante notare come per alcune porte venga riportato un valore numerico, mentre per altre un valore alfanumerico.

Valore numerico:

tcp        0      0 *:5900                  *:*                     LISTEN

Valore alfanumerico:

tcp        0      0 *:netbios-ssn           *:*                     LISTEN

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.

Il file /etc/services è un file testuale che associa un numero di porta numerico alla descrizione alfanumerica del servizio associato alla stessa.

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

$ cat /etc/services |grep netbios-ssn
netbios-ssn     139/tcp                         # NETBIOS session service
netbios-ssn     139/udp

Nel nostro esempio, dato che la porta era di tipo TCP, il valore cercato è il primo ottenuto.

Agendo sul file /etc/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 /etc/services ed aggiungere la linea:

vnc-server      5900/tcp        vnc-server      # TightVNC Server

A questo punto avremo realizzato l'associazione porta/descrizione:

# netstat -l |grep tcp
[...]
tcp        0      0 *:vnc-server            *:*                     LISTEN
[...]

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 i quali appunto GNU/Linux) è che qualsiasi elemento del sistema viene visto come se fosse un file. Abbiamo file veri e propri (ad es.: pippo.txt), abbiamo 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 file 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 della descrizione del comando: lsof = LS Open Files, cioè LiSt Open Files (elenca i file aperti).

Dato che le connessioni di rete sono rappresentate da veri e propri file, possiamo usare lsof per ottenere informazioni su di esse.

Poniamo il caso di voler ottenere informazioni sul servizio:

tcp        0      0 *:netbios-ssn           *:*                     LISTEN

Sarà sufficiente utilizzare lsof:

# lsof -i |grep netbios-ssn
smbd      4089        root   21u  IPv4   8082       TCP *:netbios-ssn (LISTEN)

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...

# 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)

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 patch 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 ad 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

# 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


Ora vediamo quale pacchetto contiene /usr/sbin/smbd:

# apt-file search /usr/sbin/smbd
samba: usr/sbin/smbd
samba-dbg: usr/lib/debug/usr/sbin/smbd

Controlliamo quale di essi sia presente nel nostro sistema:

# 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)




Guida scritta da: Keltik 05:26, Giu 23, 2005 (EDT) Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

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