Red Hat Enterprise Linux Red Hat Enterprise Linux Deployment Guide

Transcript

1 Red Hat Enterprise Linux Red Hat Enterprise Linux Deployment Guide

2 Red Hat Enterprise Linux 5.0.0: Red Hat Enterprise Linux Deployment Guide Copyright 2007 Red Hat, Inc. This Deployment Guide documents relevant information regarding the deployment, configuration and administration of Red Hat Enterprise Linux Varsity Drive Raleigh, NC USA Phone: Phone: Fax: PO Box Research Triangle Park, NC USA Documentation-Deployment Copyright 2007 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, V1.0 or later (the latest version is presently available at Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder. Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other countries. All other trademarks referenced herein are the property of their respective owners. The GPG fingerprint of the key is: CA B D6 9D FC 65 F6 EC C CD DB 42 A6 0E

3

4 Sommario Introduzione... vii 1. Inviateci suggerimenti!... vii I. Configurazione relativa alla rete Interfacce di rete File di configurazione per la rete File di configurazione delle interfacce Interfacce Ethernet Interfacce IPsec Interfacce Channel Bonding File alias e cloni Interfacce di dialup Altre interfacce Script di controllo delle interfacce File di funzione di rete Risorse addizionali Documentazione Installata Configurazione di rete Panoramica Stabilire una connessione Ethernet Stabilire una connessione ISDN Stabilire una connessione via modem Stabilire una connessione xdsl Stabilire una connessione Token Ring Stabilire una connessione di tipo wireless Gestione impostazioni DNS Gestione host Lavorare con i profili Alias per dispositivi Salvare e ripristinare la configurazione della rete BIND (Berkeley Internet Name Domain) Introduzione a DNS Zone del server dei nomi Tipi di server dei nomi BIND come un server dei nomi /etc/named.conf Tipo di istruzioni comuni Altri tipi di istruzione Tag di commento File zone Direttive dei file zone Informazioni sulla risorsa del file zone Esempi di file zone File zone per la risoluzione inversa dei nomi Uso di rndc Configurazione di /etc/named.conf...56 iv

5 Red Hat Enterprise Linux Configurazione di /etc/rndc.conf Opzioni della linea di comando BIND: caratteristiche avanzate Miglioramenti del protocollo DNS Visualizzazioni multiple Sicurezza IP versione Errori comuni da evitare Risorse aggiuntive Documentazione installata Siti Web utili Libri correlati OpenSSH Caratteristiche di SSH Perchè utilizzare OpenSSH? Versioni del protocollo SSH Sequenza eventi di un collegamento SSH Livello di trasporto Autenticazione Canali Configurazione di un server OpenSSH SSH necessario per collegamenti remoti File di configurazione di OpenSSH Configurazione del client OpenSSH Uso del comando ssh Uso del comando scp Utilizzo del comando sftp Più di una semplice Secure Shell X11 Forwarding Port Forwarding Come generare le coppie di chiavi Risorse aggiuntive Documentazione installata Siti Web utili Dynamic Host Configuration Protocol (DHCP) Perché usare il DHCP? Configurazione di un server DHCP File di configurazione Database degli affitti Avvio e arresto del server Relay Agent DHCP Configurazione di un client DHCP Risorse aggiuntive Documentazione installata FTP Il File Transport Protocol Porte multiple, Modalità multiple Sever FTP vsftpd File installati con vsftpd...88 v

6 Red Hat Enterprise Linux Avvio e arresto di vsftpd Avvio di copie multiple di vsftpd Opzioni di configurazione vsftpd Opzioni del demone Opzioni di log in e controlli d'accesso Opzioni per l'utente anonimo Opzioni dell'utente locale Opzioni della directory Opzioni di trasferimento del file Opzioni di Logging Opzioni della rete Risorse aggiuntive Documentazione installata Siti web utili II. Configurazione del sistema Configurazione del sistema X Window Impostazioni del display Impostazioni hardware del display Impostazioni del display Dual Head III. Sicurezza ed autenticazione Panoramica sulla sicurezza Valutazione dei punti deboli Pensare come il nemico Definizione di valutazione e di prova Valutazione degli strumenti Aggiornamenti sulla sicurezza Aggiornare i pacchetti Rendere sicura la tua rete Wrapper TCP e xinetd Wrapper TCP File di configurazione dei Wrapper TCP xinetd File di configurazione di xinetd Risorse aggiuntive vi

7 Introduzione Benvenuti alla Red Hat Enterprise Linux Deployment Guide. La Red Hat Enterprise Linux Deployment Guide contiene le informazioni su come personalizzare il vostro sistema Red Hat Enterprise Linux in modo da far fronte alla vostre necessità. Se state cercando una guida completa per la configurazione e la personalizzazione del vostro sistema, questo è il manuale che fà per voi. Questa guida presuppone una conoscenza di base del vostro sistema Red Hat Enterprise Linux. Se avete bisogno di assistenza durante l'installazione di Red Hat Enterprise Linux, consultate la Red Hat Enterprise Linux Installation Guide. 1. Inviateci suggerimenti! Se individuate degli errori nella Red Hat Enterprise Linux Deployment Guide, o se pensate di poter contribuire al miglioramento di questo manuale, inviate i vostri suggerimenti a Bugzilla ( in relazione al componente Deployment_Guide. Se avete un suggerimento per migliorare il documento, cercate di essere il più specifici possibile. Indicate il paragrafo e alcune righe di testo, in modo da agevolare la ricerca dell'errore. vii

8 Parte I. Configurazione relativa alla rete Dopo aver configurato la rete, questa sezione affronta gli argomenti relativi al networking, ad esempio come abilitare i login remoti, come condividere i file e le directory attraverso la rete, e come impostare un Web server.

9 Capitolo 1. Interfacce di rete Con Red Hat Enterprise Linux, tutte le comunicazioni di rete avvengono fra interfacce software configurate e dispositivi di networking fisici collegati al sistema. I file di configurazione delle interfacce di rete sono contenuti nella directory / etc/sysconfig/network-scripts. Gli script utilizzati per attivare e disattivare le suddette interfacce di rete sono anch'essi presenti all'interno della stessa directory. Anche se il numero ed il tipo dei file dell'interfaccia può variare da sistema a sistema, sono presenti tre categorie di file in questa directory: 1. file di configurazione dell'interfaccia 2. script di controllo dell'interfaccia 3. file di funzione della rete I file, in ognuno di questa categoria, lavorano insieme per abilitare vari dispositivi di rete. Questo capitolo spiega il rapporto esistente tra questi file e come essi vengono usati. 1. File di configurazione per la rete Prima di trattare i file di configurazione delle interfacce, parleremo dei file di configurazione primari usati nella configurazione di rete. Comprendere l'importanza del ruolo di questi file nell'impostazione dello stack di rete, può essere utile per imparare a personalizzare al meglio un sistema Red Hat Enterprise Linux. I file primary di configurazione di rete sono i seguenti: /etc/hosts Lo scopo principale di questo file è quello di risolvere gli hostname che non si possono risolvere in altro modo. Può anche essere utilizzato per risolvere gli hostname su piccole reti prive di server DNS. Indipendentemente dal tipo di rete su cui si trova il computer, questo file dovrebbe contenere una linea in cui è specificato l'indirizzo IP del dispositivo di loopback ( ) come localhost.localdomain. Per maggiori informazioni, consultate la pagina man hosts. /etc/resolv.conf Questo file specifica l'indirizzo IP dei server DNS e il dominio di ricerca. Se non configurato diversamente, questo file viene popolato dagli script di inizializzazione della rete. Per ulteriori informazioni su questo file, consultate la pagina man resolv.conf. /etc/sysconfig/network-scripts/ifcfg-<interface-name> Per ogni interfaccia di rete, vi è uno script di configurazione dell'interfaccia corrispondente. Ognuno di questi file fornisce informazioni specifiche in merito a una determinata interfaccia di rete. Per ulteriori dettagli su questo tipo di file e sulle direttive che accetta, consultate Sezione 2, File di configurazione delle interfacce. 2

10 2. File di configurazione delle interfacce Avvertenza La directory /etc/sysconfig/networking/ viene usata da Tool di gestione della rete (system-config-network) e il suo contenuto non dovrebbe essere modificato manualmente. È fortemente consigliato l'utilizzo di un solo metodo per la configurazione di rete per evitare così di cancellare la configurazione. 2. File di configurazione delle interfacce I file di configurazione delle interfacce controllano il funzionamento di un determinato dispositivo di interfaccia di rete. All'avvio del sistema, Red Hat Linux utilizza i file per determinare quali interfacce attivare automaticamente e come configurarle in modo corretto. Solitamente, i file sono chiamati ifcfg-<nome>, dove <nome> si riferisce al nome del dispositivo controllato dal file di configurazione Interfacce Ethernet Uno dei file più comuni è ifcfg-eth0, il quale controlla la prima scheda di interfaccia di rete o NIC nel sistema. Un sistema con più schede NIC contiene diversi file ifcfg-eth numerati. Poiché ogni dispositivo ha il proprio file di configurazione, l'utente può controllare da vicino il funzionamento di ogni singola interfaccia. Di seguito viene riportato un esempio di un file ifcfg-eth0 per un sistema che utilizza un indirizzo IP fisso: DEVICE=eth0 BOOTPROTO=none ONBOOT=yes NETWORK= NETMASK= IPADDR= USERCTL=no I valori richiesti in un file di configurazione dell'interfaccia, possono variare in funzione di altri valori. Per esempio, il file ifcfg-eth0 di un'interfaccia che utilizza DHCP è piuttosto diverso, a causa del fatto che le informazioni IP sono ora fornite dal server DHCP: DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes Potete anche modificare manualmente il file di configurazione per una determinata interfaccia di rete. In ogni file di configurazione delle interfacce sono presenti i valori seguenti: BOOTPROTO=<protocol> dove <protocol> è uno di questi: none non utilizzare alcun protocollo di avvio. bootp utilizzare il protocollo BOOTP. dhcp utilizzare il protocollo DHCP. utilizzare il protocollo DHCP. BROADCAST=<address> 3

11 2.1. Interfacce Ethernet dove <indirizzo> è l'indirizzo broadcast. Questa direttiva è stata disapprovata, in quanto il valore viene calcolato automaticamente con ifcalc. DEVICE=<name> dove <name> è il nome del dispositivo fisico (tranne per i dispositivi PPP allocati dinamicamente, dove invece corrisponde al nome logico). DHCP_HOSTNAME Usare questa opzione solo se il server DHCP richiede al client di specificare un hostname prima di ricevere un indirizzo IP. DNS{1,2}=<address> dove <address> è l'indirizzo di un server dei nomi da inserire in /etc/resolv.conf qualora la direttiva PEERDNS sia impostata su yes. ETHTOOL_OPTS=<options> dove <options> rappresenta qualsiasi delle opzioni specifiche al dispositivo supportato da ethtool. Per esempio, se desiderate forzare 100Mb, duplex completo: ETHTOOL_OPTS="autoneg off speed 100 duplex full" Nota Bene Per modificare le impostazioni duplex o la velocità, è quasi sempre necessario disabilitare autonegotiation con l'opzione autoneg off. Tale operazione deve essere eseguita per prima, poichè le entry dell'opzione seguono l'ordine prestabilito. GATEWAY=<address> dove <address> corrisponde all'indirizzo IP del router della rete o del dispositivo gateway (se presente). HWADDR=<MAC-address> dove <MAC-address> è l'indirizzo hardware del dispositivo Ethernet nella forma di AA:BB:CC:DD:EE:FF. Questa direttiva è utile per le macchine con NIC multipli, per assicurare l'assegnazione corretta dei nomi del dispositivo alle interfacce, senza dare importanza all'ordine di caricamento configurato per ogni modulo NIC. Questa direttiva non deve essere usata insieme con MACADDR. IPADDR=<address> dove <address> corrisponde all'indirizzo IP. MACADDR=<MAC-address> dove <MAC-address> è l'indirizzo hardware del dispositivo Ethernet nella forma di AA:BB:CC:DD:EE:FF. Questa direttiva viene usata per sovrascrivere l'altra assegnata al NIC fisico. Questa direttiva non dovrebbe essere assegnata insieme con HWADDR. MASTER=<bond-interface> dove <bond-interface> è l'interfaccia del channel bonding alla quale è collegata l'interfaccia Ethernet. 4

12 2.2. Interfacce IPsec Questa direttiva è usata insieme con la direttiva SLAVE. Consultate Sezione 2.3, Interfacce Channel Bonding per maggiori informazioni sulle interfacce channel bonding. NETMASK=<mask> dove <mask> è il valore della maschera di rete. NETWORK=<address> dove <address> è l'indirizzo della rete. Questa direttiva è stata deprecata, in quanto il valore viene calcolato automaticamente con ifcalc. ONBOOT=<answer> dove <answer> è una delle seguenti: yes il dispositivo dovrebbe essere attivato all'avvio. no il dispositivo non dovrebbe essere attivato all'avvio. PEERDNS=<answer> dove <answer> è una delle seguenti: yes Modifica /etc/resolv.conf se la direttiva DNS è stata impostata. Se state utilizzando DHCP, allora l'opzione yes è quella di default. no Non modificare /etc/resolv.conf. SLAVE=<bond-interface> dove <bond-interface> è una dei seguenti: yes Questo dispositivo è controllato dall'interfaccia channel bonding specificata nella direttiva MASTER. no Questo dispositivo non è controllato dall'interfaccia channel bonding specificata nella direttiva MASTER. Questa direttiva è usata insieme con la direttiva MASTER. Consultate Sezione 2.3, Interfacce Channel Bonding per maggiori informazioni sulle interfacce channel bonding. SRCADDR=<address> dove <address> è l'indirizzo IP sorgente specificato per i pacchetti in uscita. USERCTL=<answer> dove <answer> è una delle seguenti: yes gli utenti non root sono autorizzati a controllare il dispositivo. no gli utenti non root non sono autorizzati a controllare il dispositivo. 5

13 2.2. Interfacce IPsec 2.2. Interfacce IPsec Il seguente rappresenta il file ifcfg per un collegamento IPsec network-to-network per il LAN A. Il nome unico per identificare il collegamento in questo esempio è ipsec1, in questo modo il file risultante viene chiamato /etc/sysconfig/network-scripts/ifcfg-ipsec1. TYPE=IPsec ONBOOT=yes IKE_METHOD=PSK SRCNET= /24 DSTNET= /24 DST=X.X.X.X Nell'esempio sopra riportato, X.X.X.X rappresenta l'indirizzo IP publicly routable del router IPsec di destinazione. Di seguito viene riportato un elenco in ogni file di configurazione delle interfacce sono presenti i valori seguenti: DST=<address> dove <address> è l'indirizzo IP del router o dell'host di destinazione di IPsec. Esso viene usato per entrambe le configurazioni IPsec host-to-host e network-to-network. DSTNET=<network> dove <network> è l'indirizzo di rete della rete di destinazione di IPsec, e viene usato solo per i collegamenti IPsec network-to-network. SRC=<address> dove <address> è l'indirizzo IP del router o dell'host sorgente di IPsec. Questa impostazione è facoltativa e viene usata solo per i collegamenti IPsec host-to-host. SRCNET=<network> dove <tnetwork> è l'indirizzo di rete della rete sorgente IPsec. Viene usato solo per collegamenti IPsec network-to-network. TYPE=<interface-type> dove <interface-type> è IPSEC. Entrambe le applicazioni fanno parte del pacchetto ipsectools. Se avete utilizzato la cifratura manuale della chiave con IPsec, consultate / usr/share/doc/initscripts-<version-number>/sysconfig.txt (sostituite <version-number> con la versione del pacchetto initscripts installato) per i parametri di configurazione. Il demone di gestione della chiave IKEv1 di racoon tratta e configura un insieme di parametri per IPSec. È in grado di utilizzare delle chiavi pre-condivise, delle firme RSA, o GSS-API. Se viene usato racoon per gestire automaticamente la chiave di codifica, sono necessarie le seguenti opzioni: IKE_METHOD=<encryption-method> dove <encryption-method> può essere PSK, X509, o GSSAPI. Se viene specificato PSK, anche il parametro IKE_PSK deve essere impostato. Se si specifica X509, bisogna impostare il parametro IKE_CERTFILE. IKE_PSK=<shared-key> dove <shared-key> è un valore segreto condiviso per il metodo PSK (chiavi precondivise). IKE_CERTFILE=<cert-file> 6

14 2.3. Interfacce Channel Bonding dove <cert-file> è un file valido del certificato X.509 per l'host. IKE_PEER_CERTFILE=<cert-file> dove <cert-file> è un file valido del certificato X.509 per l'host remoto. IKE_DNSSEC=<answer> dove <answer> è yes. Il demone racoon riprende il certificato X.509 dell'host remoto tramite DNS. Se viene specificato un IKE_PEER_CERTFILE, non includere questo parametro. Per maggiori informazioni sugli algoritmi disponibili per IPsec, consultare la pagina man setkey. Per maggiori informazioni su racoon, consultare le pagine man racoon e racoon.conf Interfacce Channel Bonding Red Hat Enterprise Linux permette agli amministratori di unire le interfacce di rete multiple insieme in un singolo canale usando il modulo del kernel bonding e una interfaccia di rete speciale chiamata interfaccia channel bonding. Il channel bonding permette a due o più interfacce di agire come se fossero una unica interfaccia, aumentando simultaneamente la larghezza della banda fornendo così una ridondanza. Per creare una interfaccia channel bonding, creare un file nella directory / etc/sysconfig/network-scripts/ chiamato ifcfg-bond<n>, sostituendo <N> con il numero per l'interfaccia, come ad esempio 0. Il contenuto del file può essere identico a qualsiasi tipo di interfaccia alla quale ci si sta legando, come ad esempio una interfaccia Ethernet. La sola differenza è che la direttiva DEVICE= deve essere bond<n>, sostituendo <N> con il numero per l'interfaccia. Il seguente è un esempio del file di configurazione channel bonding: DEVICE=bond0 BOOTPROTO=none ONBOOT=yes NETWORK= NETMASK= IPADDR= USERCTL=no Dopo aver creato l'interfaccia channel bonding, le interfacce di rete da unire devono essere configurate aggiungendo le direttive MASTER= e SLAVE= ai loro file di configurazione. I file di configurazione per ogni interfaccia channel bonded, possono essere quasi identici. Per esempio, se il channel bonding unisce due interfacce Ethernet, sia eth0 che eth1 potrebbero somigliare al seguente esempio: DEVICE=eth<N> BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no In questo esempio, sostituire <N> con il valore numerico per l'interfaccia. Il modulo del Kernel deve essere caricato per far si che l'interfaccia channel bonding possa essere valida. Per assicurarsi che il modulo sia stato caricato quando si usa l'interfaccia channel bonding, aggiungere la seguente riga a /etc/modprobe.conf: alias bond<n> bonding Sostituire <N> con il numero dell'interfaccia, come ad esempio 0. Per ogni interfaccia channel bonding configurata, deve corrispondere una voce corrispondente in /etc/modprobe.conf. Una volta configurato /etc/modprobe.conf l'interfaccia channel bonding e le interfacce di rete è necessario usare il comando ifup per attivare l'interfaccia channel bonding. 7

15 2.5. Interfacce di dialup 2.4. File alias e cloni Due tipi di file di configurazione delle interfacce meno usati sono alias e clone. I file di configurazione dell'interfaccia Alias, i quali vengono usati principalmente per unire gli indirizzi multipli ad una singola interfaccia, usano, per il naming, il seguente schema:ifcfg-<if-name>:<alias-value>. Per esempio, un file ifcfg-eth0:0 può essere configurato in modo da specificare DEVICE=eth0:0, ed un indirizzo IP statico , servendo come alias di una interfaccia Ethernet già configurata per ricevere le proprie informazioni IP tramite DHCP in ifcfg-eth0. Con questa configurazione, il dispositivo eth0 è legato ad un indirizzo IP dinamico, ma la stessa scheda di rete fisica può ricevere alcune richieste tramite l'indirizzo IP fisso Attenzione Le interfacce alias non supportano DHCP. Un file clone di configurazione dell'interfaccia, dovrebbe usare il seguente formato, ifcfg-<if-name>-<clone-name>. Mentre un file alias abilita indirizzi multipli per una interfaccia già esistente, un file clone viene usato per specificare le opzioni aggiuntive per una interfaccia. Per esempio, una interfaccia Ethernet DHCP standard chiamata eth0, potrebbe somigliare a quanto di seguito riportato: DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp Poichè il valore di default per la direttiva USERCTL è no, se non specificata, gli utenti non possono attivare e disattivare l'interfaccia. Per dare agli utenti la possibilità di controllare l'interfaccia,create un clone copiando ifcfg-eth0 in ifcfg-eth0-user e aggiungendo la riga seguente a ifcfg-eth0- user: USERCTL=yes In questo modo l'utente attiva l'interfaccia eth0 con il comando ifup eth0-user, perchè le opzioni di configurazione di ifcfg-eth0 e ifcfg-eth0-user vengono combinate. L'esempio riportato è molto semplice, questo metodo può essere usato con varie opzioni e interfacce Interfacce di dialup Se vi collegate ad Internet tramite una connessione dialup, l'interfaccia avrà bisogno di un file di configurazione. I file dell'interfaccia PPP vengono nominati utilizzando il seguente formato: ifcfg-ppp<x> dove <X> è un numero unico corrispondente ad una interfaccia specifica. Il file di configurazione dell'interfaccia PPP viene creato automaticamente quando si utilizzano wvdial, il Tool di gestione della rete o Kppp per creare un account dialup. È possibile creare e 8

16 2.5. Interfacce di dialup modificare questo file manualmente. I file ifcfg-ppp0 hanno all'incirca questo aspetto: DEVICE=ppp0 NAME=test WVDIALSECT=test MODEMPORT=/dev/modem LINESPEED= PAPNAME=test USERCTL=true ONBOO SLIP (Serial Line Internet Protocol) è un'altra interfaccia di dialup, sebbene il suo utilizzo sia meno frequente. I file SLIP hanno nomi di file di configurazione delle interfacce quali ifcfg-sl0. Oltre opzioni che possono essere utilizzate in questi file includono: DEFROUTE=<answer> dove <answer> è una delle seguenti: yes imposta l'interfaccia come quella di default. no non imposta l'interfaccia come quella di default. DEMAND=<answer> dove <answer> è una delle seguenti: yes Questa interfaccia consente a pppd di avviare una connessione quando qualcuno tenta di usarlo. no per quest'interfaccia deve essere stabilita una connessione in modo manuale. IDLETIMEOUT=<value> dove <value> corrisponde al numero di secondi di inattività che precede lo scollegamento dell'interfaccia. INITSTRING=<string> dove <string> rappresenta la stringa di inizializzazione trasmessa al dispositivo del modem. L'opzione èessenzialmente usata con interfacce SLIP. LINESPEED=<value> dove <value> è la frequenza di baud (baud rate) del dispositivo. I valori standard possibili sono 57600, 38400, 19200, e MODEMPORT=<device> dove <device> corrisponde al nome del dispositivo seriale utilizzato per stabilire la connessione per l'interfaccia. MTU=<value> dove <value> è il parametro Maximum Transfer Unit (MTU) dell'interfaccia. Il parametro MTU si riferisce al numero massimo di byte di dati che una struttura può trasportare, senza contare le sue informazioni di testo. In alcune situazioni di dialup, impostando il parametro su di un valore di 576 ne risulta una perdita di pochi pacchetti con un leggero miglioramento sul rendimento per un collegamento. NAME=<name> dove <name> è il riferimento al titolo attribuito a un insieme di configurazioni di connessione dialup. 9

17 2.6. Altre interfacce PAPNAME=<name> dove <name> è il nome utente assegnato durante lo scambio di Password Authentication Protocol(PAP), che avviene per abilitare i collegamenti ad un sistema remoto. PERSIST=<answer> dove <answer> è una delle seguenti: yes l'interfaccia deve rimanere sempre attiva, anche dopo lo scollegamento del modem. no l'interfaccia non deve rimanere sempre attiva. REMIP=<address> dove <address> è l'indirizzo IP del sistema remoto. Solitamente non è specificato. WVDIALSECT=<name> dove <name> associa l'interfaccia alla configurazione del dialer in /etc/wvdial.conf, che contiene il numero telefonico da comporre e altre informazioni importanti per l'interfaccia Altre interfacce Ecco riportati i file di configurazione più utilizzati per le interfacce: ifcfg-lo Una interfaccia di loopback locale utilizzata per operazioni di controllo, e in molteplici applicazioni che richiedono un indirizzo IP in grado di indicare lo stesso sistema. Qualunque dato trasferito al dispositivo loopback, viene immediatamente ritornato al livello di rete dell'host. Avvertenza Non modificate mai lo script dell'interfaccia loopback / etc/sysconfig/network-scripts/ifcfg-lo manualmente. Facendo questo, il sistema operativo potrebbe non funzionare correttamente. ifcfg-irlan0 Una interfaccia ad infrarossi consente il passaggio di informazioni tra dispositivi, come un laptop e una stampante, attraverso una connessione a infrarossi che funziona in modo simile ad un dispositivo Ethernet, ad eccezione del fatto che normalmente si verifica mediante una connessione peer-to-peer. ifcfg-plip0 Una connessione Parallel Line Interface Protocol (PLIP) funziona praticamente allo stesso modo di un dispositivo Ethernet, ad eccezione di un utilizzo di una porta parallela. ifcfg-tr0 A causa di una grande diffusione di Ethernet, le topologie Token Ring non sono così diffuse sulle Local Area Networks (LAN) come erano una volta. 10

18 3. Script di controllo delle interfacce 3. Script di controllo delle interfacce Gli script di controllo delle interfacce attivano e disattivano le interfacce di sistema. Esistono due script primari di controllo delle interfacce, /sbin/ifdown e /sbin/ifup, che usano altri script di controllo contenuti nella directory /etc/sysconfig/network-scripts. Gli script delle interfacce ifdown e ifup sono link simbolici per gli script contenuti nella directory /sbin. Quando viene chiamato uno di questi script, è necessario specificare un valore dell'interfaccia come ad esempio: ifup eth0 Attenzione Gli script delle interfacce ifdown e ifup sono i soli script che l'utente dovrebbe usare per attivare e disattivare le interfacce di rete. I seguenti script sono usati solo come riferimento. Due file usati per effettuare diversi compiti di inizializzazione della rete durante il processo di attivazione di una interfaccia di rete sono /etc/rc.d/init.d/functions e / etc/sysconfig/network-scripts/network-functions. Consultate Sezione 4, File di funzione di rete per maggiori informazioni. Dopo aver verificato se è stata specificata una interfaccia e se l'utente che esegue la richiesta ha il permesso di controllare l'interfaccia, viene chiamato lo script idoneo che, in pratica, si occupa di attivare e disattivare l'interfaccia. Di seguito sono elencati gli script di controllo delle interfacce trovati all'interno della directory /etc/sysconfig/network-scripts/: ifup-aliases Configura gli alias IP dai file di configurazione delle interfacce quando più indirizzi IP sono associati con una interfaccia. ifup-ippp e ifdown-ippp Attiva e disattiva le interfacce ISDN. ifup-ipsec e ifdown-ipsec Attiva e disattiva le interfacce IPsec. ifup-ipv6 e ifdown-ipv6 Attiva e disattiva le interfacce IPv6. ifup-ipx Attiva l'interfaccia IPX. ifup-plip Attiva l'interfaccia PLIP. ifup-plusb 11

19 4. File di funzione di rete Attiva un'interfaccia USB per le connessioni di rete. ifup-post e ifdown-post Contiene comandi da eseguire dopo aver abilitato o disabilitato una interfaccia. ifup-ppp e ifdown-ppp Attiva e disattiva un'interfaccia PPP. ifup-routes Aggiunge instradamenti statici per un particolare dispositivo quando la sua interfaccia viene attivata. ifdown-sit e ifup-sit Contiene le chiamate della funzione relative all'attivazione e alla disattivazione del tunnel IPv6 all'interno di una connessione IPv4. ifup-sl e ifdown-sl Attiva e disattiva un'interfaccia SLIP. ifup-wireless Attiva un'interfaccia wireless. Avvertenza Ricordate che in seguito alla rimozione o alla modifica degli script nella directory / etc/sysconfig/network-scripts/ varie connessioni dell'interfaccia, possono agire in modo inaspettato. Pertanto solo utenti esperti possono modificare gli script relativi all'interfaccia della rete. Il modo più facile per manipolare tutti gli script di rete contemporaneamente è di usare il comando /sbin/service sul servizio di rete (/etc/rc.d/init.d/network), come illustrato nel seguente comando: /sbin/service network <action> In questo esempio, <azione> può essere start, stop, o restart. Per visualizzare un'elenco dei dispositivi configurati e che sono attualmente attivi sulle interfacce di rete, utilizzate il comando: /sbin/service network status 4. File di funzione di rete Red Hat Enterprise Linux utilizza diversi file che contengono funzioni comuni importanti, usati per attivare e disattivare le interfacce. Invece di forzare ogni file di controllo delle interfacce a contenere queste funzioni, esse sono riunite in alcuni file che possono essere utilizzati quando necessario. Il file /etc/sysconfig/network-scripts/network-functions contiene le funzioni IPv4 più utilizza- 12

20 5. Risorse addizionali te, utili per molti script di controllo delle interfacce. Queste funzioni consentono di contattare i programmi in esecuzione che hanno richiesto informazioni sui cambiamenti dello stato in una interfaccia, impostare gli hostname, trovare un dispositivo gateway, controllare se un dispositivo è attivo o inattivo e aggiungere un instradamento di default. Poichè le funzioni richieste per le interfacce IPv6 sono diverse da quelle delle interfacce IPv4, è disponibile un file /etc/sysconfig/network-scripts/network-functions-ipv6 in grado di contenere tutte queste informazioni. Le funzioni in questi file possono configurare e cancellare gli instradamenti IPv6 statici, aggiungono e rimuovono i tunnel, aggiungono e rimuovono indirizzi IPv6 da una interfaccia e verificano l'esistenza di un indirizzo IPv6 in una interfaccia. 5. Risorse addizionali Le seguenti risorse spiegano in modo più dettagliato le interfacce di rete Documentazione Installata /usr/share/doc/initscripts-<version>/sysconfig.txt Una guida alle opzioni disponibili per i file di configurazione della rete, comprese le opzioni IPv6, non trattate in questo capitolo. /usr/share/doc/iproute-<version>/ip-cref.ps Questo file contiene una ricca fonte di informazione sul comando ip, che può essere utilizzato anche per manipolare le tabelle di instradamento. Per consultare questo file, utilizzate ggvo kghostview. 13

21 Capitolo 2. Configurazione di rete Per poter comunicare tra loro, i computer avranno bisogno di un collegamento di rete. Ciò è reso possibile utilizzando un sistema operativo in grado di riconoscere una scheda di interfaccia (come ad esempio Ethernet, modem ISDN, o token ring) e di configurarla in modo da connettersi alla rete. Tool di gestione della rete permette di configurare le seguentiinterfacce di rete: Ethernet ISDN modem xdsl token ring CIPE dispositivi wireless Può anche essere usato per configurare i collegamenti IPsec, gestire le impostazioni DNS, e gestire il file /etc/hosts usato per conservare gli hostname aggiuntivi e le combinazioni dell'indirizzo IP. Per utilizzare Tool di gestione della rete, dovete avere i privilegi root. Per avviare l'applicazione selezionata andate su Applications (the main menu on the panel) => Impostazioni di sistema => Rete oppure digitate il comando redhat-config-network al prompt della shell (per esempio, in un XTerm o in un terminale GNOME). Se digitate il comando, viene mostrata la versione grafica se X é in esecuzione, altrimenti verrá visualizzata la versione di testo. Per usare la versione a linea di comando, eseguire il comando system-config-network-cmd - -help come utente root per visualizzare tutte le opzioni. 14

22 1. Panoramica Figura 2.1. Tool di gestione della rete Suggerimento Consultate l'hardware Compatibility List di Red Hat sul sito ( per verificare se Red Hat Enterprise Linux è in grado di supportare il vostro dispositivo hardware. 1. Panoramica Per configurare un collegamento di rete con Tool di gestione della rete, seguite le fasi di seguito riportate: 1. Aggiungete un dispositivo di rete associato all'hardware fisico. 15

23 2. Stabilire una connessione Ethernet 2. Se non è già presente, aggiungete il dispositivo hardware fisico all'elenco hardware. 3. Configurate gli hostname e le impostazioni DNS. 4. Configurate gli hostname e le impostazioni DNS. Questo capitolo illustra le procedure per ciascun tipo di connessione di rete. 2. Stabilire una connessione Ethernet Per stabilire una connessione Ethernet, sono necessari una scheda di interfaccia (NIC), un cavo di rete (in genere un cavo CAT5) e una rete cui connettersi. Poiché esistono diverse velocità di connessione, assicuratevi la vostra NIC sia compatibile con la rete cui desiderate connettervi. Per aggiungere una connessione Ethernet, eseguite le seguenti procedure: 1. Fate clic sulla scheda Dispositivi. 2. Fate clic sul pulsante Nuovosulla barra degli strumenti. 3. Selezionate la voce Ethernet connection dall'elenco Tipo di dispositivo, e fate clic su Forward. 4. Se avete già aggiunto la scheda di interfaccia di rete all'elenco hardware, selezionate la voce corrispondente dall'elenco Ethernet card. In caso contrario, selezionate Other Ethernet Card per aggiungere il dispositivo hardware. Nota Bene Normalmente, il programma di installazione individua automaticamente i dispositivi Ethernet supportati e vi chiede di configurarli. Se durante l'installazione avete configurato dei dispositivi Ethernet, questi verranno visualizzati nell'elenco hardware all'interno della scheda Hardware. 5. Se avete selezionato Altra scheda Ethernet, visualizzerete la finestra Seleziona adattatore Ethernet. Selezionate il produttore e il modello della scheda Ethernet, quindi il nome del dispositivo. Se si tratta della prima scheda Ethernet del sistema, selezionate eth0 come nome, se invece risulta essere la seconda selezionate eth1, e così via. Il Tool di gestione della rete vi consente anche di configurare le risorse per la NIC. Fate clic su Avanti per continuare. 6. Nella finestra Configura impostazioni di rete come riportato in Figura 2.2, Impostazioni Ethernet, scegliete tra DHCP ed un indirizzo IP statico. Non specificate l'hostname se il dispositivo riceve un indirizzo IP diverso ogni qualvolta viene stabilita la connessione di rete. Fate clic su Avanti per continuare. 7. Fate clic su Applica nella pagina Create Ethernet Device. 16

24 2. Stabilire una connessione Ethernet Figura 2.2. Impostazioni Ethernet Dopo aver configurato il dispositivo Ethernet, esso verrà visualizzato nell'elenco del dispositivo come mostrato dalla Figura 2.3, Dispositivo Ethernet. 17

25 2. Stabilire una connessione Ethernet Figura 2.3. Dispositivo Ethernet Assicurarsi di selezionare File => Salva per cambiare i cambiamenti. Dopo aver aggiunto il dispositivo Ethernet, è possibile modificarne le impostazioni selezionando la voce relativa dall'elenco dispositivi e cliccando su Modifica. Per esempio, quando aggiungete il dispositivo, questo verrà lanciato di default all'avvio del sistema. Per cambiare questa impostazione, scegliere di modificare il dispositivo, modificare il valore Attivare il dispositivo quando si avvia il computer, e salvare i cambiamenti. Quando viene aggiunto un dispositivo, esso non viene attivato immediatamente, come mostrato dal proprio stato Inattivo. Per attivarlo, selezionarlo dall'elenco e fate clic sul pulsante Attivare. Se il sistema é configurato per attivare il dispositivo al momento dell'avvio del computer (di default), questa fase non deve essere eseguita. Associando più di un dispositivo con una scheda Ethernet, i dispositivi seguenti sono alias del dispositivo. Un alias del dispositivo vi permette di impostare dispositivi virtuali multipli per un singolo dispositivo fisico, conferendo così al dispositivo fisico stesso piú di un indirizzo IP. Per esempio è possible configurare un dispositivo eth1 ed un dispositivo eth1:1. Per maggiori infor- 18

26 3. Stabilire una connessione ISDN mazioni consultate Sezione 11, Alias per dispositivi. 3. Stabilire una connessione ISDN La connessione ISDN è una connessione Internet stabilita mediante una scheda modem ISDN attraverso una speciale linea telefonica installata dalla società dei telefoni. Questo tipo di connessione è diffuso in Europa. Per aggiungere una connessione ISDN eseguite le seguenti procedure: 1. Fate clic sulla scheda Dispositivi. 2. Fate clic sul pulsante Nuovosulla barra degli strumenti. 3. Nell'elenco Tipo di dispositivo, selezionate ISDN connection e fate clic su Forward. 4. Selezionate l'adattatore ISDN dal menu a tendina. Configurate poi le risorse di sistema e il Protocollo Canale D. Fate clic su Forward per continuare. Figura 2.4. Impostazioni ISDN 5. Selezionate l'isp, se presente nell'elenco preconfigurato. In caso contrario, inserite le informazioni richieste relative al vostro account con il provider. Se non conoscete i valori richiesti, contattate direttamente l'isp. Fate clic su Forward. 6. Nella finestra Impostazioni IP, selezionate Modalitá Encapsulation, e se ottenere un indirizzo IP tramite DHCP o impostarne uno in modo statico. Fate clic su Avanti quando avete terminato. 7. Nella pagina Create Dialup Connection, fate clic su Applica. 19

27 4. Stabilire una connessione via modem Dopo aver terminato la configurazione del dispositivo ISDN, esso comparirà nell'elenco del dispositivo come un dispositivo di tipo ISDN come mostra la Figura 2.5, Dispositivo ISDN. Assicurarsi di selezionare File => Salva per cambiare i cambiamenti. Una volta aggiunto il dispositivo ISDN, è possibile modificarne le impostazioni selezionando la voce relativa dall'elenco dispositivi e facendo clic su Modifica. Per esempio, quando aggiungete il dispositivo, questo verrà lanciato di default all'avvio del sistema, ma cambiando la sua configurazione potete modificarne l'impostazione. Potete intervenire anche in merito a compressione, opzioni PPP, nome di login, password e altro ancora. Quando viene aggiunto un dispositivo, esso non viene attivato immediatamente, come mostrato dal proprio stato Inattivo. Per attivarlo, selezionarlo dall'elenco e fate clic sul pulsante Attivare. Se il sistema é configurato per attivare il dispositivo al momento dell'avvio del computer (di default), questa fase non deve essere eseguita. Figura 2.5. Dispositivo ISDN 20

28 4. Stabilire una connessione via modem 4. Stabilire una connessione via modem Il modem consente di configurare la connessione Internet attraverso una linea telefonica attiva. È necessario disporre di un account con un provider di servizi Internet (ISP) (definito anche account dial-up). Per aggiungere una connessione via modem, eseguite la seguente procedura: 1. Fate clic sulla scheda Dispositivi. 2. Fate clic sul pulsante Nuovosulla barra degli strumenti. 3. Nell'elenco Tipo di dispositivo, selezionate Modem connection e fate clic su Forward. 4. Se nell'elenco modem (alla voce Hardware) è presente un modem già configurato, il Tool di gestione della rete presume vogliate utilizzarlo per stabilire una connessione via modem. In caso contrario, andrà alla ricerca di qualsiasi modem installato sul sistema. Questa operazione potrebbe richiedere del tempo. Se il modem non viene trovato, viene visualizzato un messaggio avvisandovi che le impostazioni mostrate non sono valori trovati dalla ricerca. 5. Dopo aver eseguito una prova comparirà la finestra in Figura 2.6, Impostazioni modem. Figura 2.6. Impostazioni modem 6. Configurate la frequenza baud, il controllo di flusso e il volume del modem. Se non conoscete questi valori, accettate quelli predefiniti. Se non usate la composizione a toni, deselezionate la casella di spunta corrispondente. Fate clic su Forward. 7. Selezionate l'isp, se presente nell'elenco preconfigurato. In caso contrario, inserite le infor- 21

29 4. Stabilire una connessione via modem mazioni richieste relative al vostro account con il provider. Se non conoscete i valori richiesti, contattate direttamente l'isp. Fate clic su Forward. 8. Sulla pagina Impostazioni IP, scegliete se ottenere un indirizzo IP automaticamente oppure impostarne uno in modo statico. Fate clic su Avanti quando avete terminato. 9. Nella pagina Create Dialup Connection, fate clic su Applica. Terminata la configurazione del dispositivo modem, esso comparirà nell'elenco dispositivi con la tipologia Modem come mostrato nella Figura 2.7, Dispositivo modem. Figura 2.7. Dispositivo modem Assicurarsi di selezionare File => Salva per cambiare i cambiamenti. Una volta aggiunto il dispositivo modem, è possibile modificarne le impostazioni selezionando la voce relativa dall'elenco dispositivi e facendo clic su Modifica. Per esempio, quando aggiungete il dispositivo, questo verrà lanciato di default all'avvio del sistema, ma cambiando la sua configurazione potete modificarne l'impostazione. Potete intervenire anche in merito a compressione, opzioni PPP, nome di login, password e altro ancora. 22

30 5. Stabilire una connessione xdsl Quando viene aggiunto un dispositivo, esso non viene attivato immediatamente, come mostrato dal proprio stato Inattivo. Per attivarlo, selezionarlo dall'elenco e fate clic sul pulsante Attivare. Se il sistema é configurato per attivare il dispositivo al momento dell'avvio del computer (di default), questa fase non deve essere eseguita. 5. Stabilire una connessione xdsl DSL è l'acronimo di Digital Subscriber Lines. Esistono diversi tipi di DSL come ADSL, IDSL e SDSL. Il Tool di gestione della rete utilizza il termine xdsl con riferimento a tutti i tipi di collegamento DSL. Alcuni provider DSL richiedono di configurare il sistema per ottenere un indirizzo IP mediante DHCP con una scheda Ethernet, mentre altri necessitano una connessione PPPoE (Point-to-Point Protocol su Ethernet) con una scheda Ethernet. Chiedete al vostro provider DSL quale metodo usare. Se è richiesto l'uso del DHCP, consultate Sezione 2, Stabilire una connessione Ethernet per configurare la scheda Ethernet. Se è richiesto l'uso del PPPoE, seguite le istruzioni riportate: 1. Fate clic sulla scheda Dispositivi. 2. Fate clic sul pulsante Aggiungi. 3. Nell'elenco Tipo di dispositivo, selezionate xdsl connection e fate clic su Forward. 4. Se la vostra scheda Ethernet è presente nell'elenco hardware, selezionate la voce Dispositivo Ethernet dal menu a tendina della pagina mostrata nella Figura 2.8, Impostazioni xdsl Altrimenti, apparirà la finestra Seleziona adattatore Ethernet. Nota Bene Normalmente, il programma di installazione individua automaticamente i dispositivi Ethernet supportati e vi chiede di configurarli. Se durante l'installazione avete configurato dei dispositivi Ethernet, questi verranno visualizzati nell'elenco hardware all'interno della scheda Hardware. 23

31 5. Stabilire una connessione xdsl Figura 2.8. Impostazioni xdsl 5. Se verrà visualizzata finestra Seleziona adattatore ethernet, selezionate il produttore ed il modello della scheda Ethernet, quindi il nome del dispositivo. Se si tratta della prima scheda Ethernet del sistema, selezionate eth0 come nome del dispositivo, se invece si tratta della seconda, allora selezionate eth1, e così via. Il Tool di gestione della rete vi consente anche di configurare le risorse per il NIC. Fate clic su Avanti per continuare. 6. Inserite le informazioni necessarie nei campi Provider Name, Login Name, e Password. Se avete un account T-Online, invece di inserire un Login Name e Password nella finestra di default, fate clic sul pulsante T-Online Account Setup e inserire le informazioni necessarie. Fate clic su Forward per continuare. 7. Nella pagina Create DSL Connection, fate clic su Applica. Dopo aver configurato il collegamento DSL, esso comparirà nell'elenco dispositivi, come mostrato nella Figura 2.7, Dispositivo modem. 24

32 6. Stabilire una connessione Token Ring Figura 2.9. Dispositivo xdsl Assicurarsi di selezionare File => Salva per cambiare i cambiamenti. Una volta aggiunta la connessione xdsl, è possibile modificarne le impostazioni selezionando la voce relativa dall'elenco dispositivi e facendo clic su Modifica. Per esempio, quando aggiungete il dispositivo, questo verrà lanciato di default all'avvio del sistema, ma potete modificarne l'impostazione cambiando la sua configurazione. Quando viene aggiunto un dispositivo, esso non viene attivato immediatamente, come mostrato dal proprio stato Inattivo. Per attivarlo, selezionarlo dall'elenco e fate clic sul pulsante Attivare. Se il sistema é configurato per attivare il dispositivo al momento dell'avvio del computer (di default), questa fase non deve essere eseguita. 6. Stabilire una connessione Token Ring Un token ring network è una rete dove tutti i computer sono connessi in modo circolare. I computer possono scambiare le informazioni tramite il token, un pacchetto di rete speciale, che cir- 25

33 6. Stabilire una connessione Token Ring cola sulla token ring e consente ai computer stessi di inviarsi informazioni. Suggerimento Per ulteriori informazioni sull'impiego di token ring con Linux, consultate il sito Web Linux Token Ring Project all'indirizzo Per aggiungere una connessione token ring, eseguite le seguenti procedure: 1. Fate clic sulla scheda Dispositivi. 2. Fate clic sul pulsante Nuovosulla barra degli strumenti. 3. Nell'elenco Tipo di dispositivo, selezionate Token Ring connection e fate clic su Forward. 4. Se avete già aggiunto la scheda token ring all'elenco hardware, selezionate la voce relativa dall'elenco Ethernet card. Altrimenti, selezionate la voce Other Tokenring Card per aggiungere il dispositivo hardware. 5. Se avete selezionato Altra scheda Tokenring, apparirà la finestra Seleziona adattatore Token Ring, come mostrato nella Figura 2.10, Impostazioni token ring. Selezionate il produttore e il modello dell'adattatore, quindi il nome del dispositivo. Se si tratta della prima scheda token ring del sistema, selezionate tr0, se invece è la seconda selezionate tr1, (e così via). Il Tool di gestione della rete vi consente anche di configurare le risorse di sistema per l'adattatore. Fate clic su Avanti per continuare. 26

34 6. Stabilire una connessione Token Ring Figura Impostazioni token ring 6. Nella pagina Configure Network Settings, specificate il DHCP, l'indirizzo IP statico, ed eventualmente l'hostname. Se il dispositivo riceve un indirizzo IP dinamico ogni volta che viene attivata la connessione di rete, non specificate l'hostname. Fate clic su Forward per continuare. 7. Fate clic su Applica nella pagina Create Ethernet Device. Dopo aver configurato il dispositivo token ring, esso comparirà nell'elenco dei dispositivi, come mostra la Figura 2.11, Dispositivo token ring. 27

35 7. Stabilire una connessione di tipo wireless Figura Dispositivo token ring Assicurarsi di selezionare File => Salva per cambiare i cambiamenti. Una volta aggiunto il dispositivo, è possibile modificarne le impostazioni selezionando la voce relativa dall'elenco dispositivi e facendo clic su Modifica. Per esempio, potete stabilire se lanciarlo all'avvio del sistema. Quando viene aggiunto un dispositivo, esso non viene attivato immediatamente, come mostrato dal proprio stato Inattivo. Per attivarlo, selezionarlo dall'elenco e fate clic sul pulsante Attivare. Se il sistema é configurato per attivare il dispositivo al momento dell'avvio del computer (di default), questa fase non deve essere eseguita. 7. Stabilire una connessione di tipo wireless I dispositivi wireless sono sempre più utilizzati. La loro configurazione è simile a quella di un dispositivo Ethernet, ma offre anche la possibilità di impostare l'ssid, e il tasto per il dispositivo wireless. 28

36 7. Stabilire una connessione di tipo wireless Per aggiungere una connessione Ethernet wireless, eseguite la seguente procedura: 1. Fate clic sulla scheda Dispositivi. 2. Fate clic sul pulsante Nuovosulla barra degli strumenti. 3. Nell'elenco Tipo di dispositivo, selezionate Wireless connection e fate clic su Avanti. 4. Se avete già aggiunto la scheda di interfaccia di rete wireless all'elenco hardware, selezionate la voce relativa dall'elenco Ethernet card. Altrimenti, selezionate Other Ethernet Card per aggiungere il dispositivo hardware. Nota Bene Generalmente, il programma di installazione individua i dispositivi Ethernet wireless supportati e ne richiede la configurazione. Eventuali dispositivi configurati durante l'installazione saranno visualizzati nell'elenco hardware alla voce Hardware. 5. Se avete selezionato Altra scheda Wireless, apparirà la finestra Seleziona adattatore Ethernet. Selezionate il produttore e il modello della scheda Ethernet, quindi il dispositivo. Se si tratta della prima scheda Ethernet del sistema, selezionate eth0, se invece risulta essere la seconda selezionate eth1, e così via. Il Tool di gestione della rete vi consente anche di configurare le risorse di sistema per la scheda di interfaccia di rete wireless. Fate clic su Avanti per continuare. 6. Sulla pagina Configura collegamento Wireless come mostrato in Figura 2.12, Impostazioni wireless, configurate le impostazioni per il dispositivo wireless. 29

37 7. Stabilire una connessione di tipo wireless Figura Impostazioni wireless 7. Nella pagina Configure Network Settings, specificate il DHCP, l'indirizzo IP statico, ed eventualmente l'hostname. Se il dispositivo riceve un indirizzo IP dinamico ogni volta che viene attivata la connessione di rete, non specificate l'hostname. Fate clic su Forward per continuare. 8. Fate clic su Applica nella pagina Create Wireless Device. Dopo aver configurato il dispositivo wireless, esso apparirà nell'elenco dei dispositivi come mostrato nella Figura 2.13, Dispositivo wireless. 30

38 8. Gestione impostazioni DNS Figura Dispositivo wireless Assicurarsi di selezionare File => Salva per cambiare i cambiamenti. Una volta aggiunto il dispositivo wireless, è possibile modificarne le impostazioni selezionando la voce relativa dall'elenco dispositivi e facendo clic su Modifica. Per esempio, potete configurarlo affinché si attivi all'avvio del sistema. Quando viene aggiunto un dispositivo, esso non viene attivato immediatamente, come mostrato dal proprio stato Inattivo. Per attivarlo, selezionarlo dall'elenco e fate clic sul pulsante Attivare. Se il sistema é configurato per attivare il dispositivo al momento dell'avvio del computer (di default), questa fase non deve essere eseguita. 8. Gestione impostazioni DNS La scheda DNS consente di configurare l'hostname di sistema, il dominio, i name server e il dominio di ricerca. I name server sono utilizzati per consultare altri host sulla rete. Se i nomi del server DNS vengono ripresi da DHCP o PPPoE (oppure da ISP), non aggiungere 31

39 8. Gestione impostazioni DNS server DNS primari, secondari e terziari. Se l'hostname viene ripreso in modo dinamico da DHCP o PPPoE (oppure ISP), non cambiatelo. Figura Configurazione DNS Nota Bene La sezione dei server del nome non configura il sistema per essere un server dei nomi. Invece, essa configura i suddetti server ad un loro utilizzo per risolvere l'indirizzo IP in hostname e viceversa. 32

40 9. Gestione host Attenzione! Se l'hostname risulta essere diverso e system-config-network è stato avviato sull'host locale, molto probabilmente non sarete in grado di avviare un'altra applicazione X11. Per questo motivo sarà necessario eseguire nuovamente il login in una sessione desktop nuova. 9. Gestione host La scheda Host consente di aggiungere, modificare o rimuovere gli host dal file /etc/hosts. Questo contiene gli indirizzi IP e gli hostname relativi. Quando il vostro sistema cerca di risolvere un hostname per un indirizzo IP oppure di determinarne uno, esso farà riferimento al file /etc/hosts, utilizzando dapprima i name server (se usate la configurazione di default di Red Hat Enterprise Linux). Se l'indirizzo IP si trova nell'elenco del file /etc/hosts, i name server non vengono utilizzati. Se gli indirizzi IP dei computer della vostra rete non si trovano nell'elenco DNS, è consigliabile aggiungerli nel file /etc/hosts. Per aggiungere una voce al file /etc/hosts, andate su Host, selezionate Nuovo, fornite le informazioni richieste, quindi fate clic su OK. Selezionate File => Salva o premete Ctrl-S per salvare i cambiamenti sul file /etc/hosts. La rete o i servizi di rete non necessitano di essere riavviati poichè la versione attuale viene riferita ogni qualvolta viene risolto un indirizzo. Attenzione! Non rimuovere la voce localhost. Anche se il sistema non possiede una connessione di rete o una connessione eseguita costantemente, alcuni programmi necessitano di collegarsi al sistema tramite l'interfaccia loopback del localhost. 33

41 10. Lavorare con i profili Figura Configurazione host Suggerimento Per modificare l'ordine di consultazione, modificate il file /etc/host.conf. La riga order hosts, bind specificare che /etc/hosts ha precedenza sui name server nomi. Modificando la riga in order bind, hosts, il sistema sarà configurato per risolvere gli hostname e gli indirizzi IP usando dapprima i name server. Se l'indirizzo IP non può essere risolto mediante i name server, il sistema cerca gli indirizzi IP nel file /etc/hosts. 10. Lavorare con i profili È possibile creare molteplici dispositivi logici di rete per ciascun dispositivo hardware fisico. Per esempio, se avete una scheda Ethernet sul vostro sistema (eth0), potete creare vari dispositivi 34

42 10. Lavorare con i profili logici di rete associati a eth0 con nickname diversi e opzioni di configurazione diverse. I dispositivi logici di rete sono diversi dagli alias. I dispositivi logici di rete associati allo stesso dispositivo fisico devono esistere all'interno di profili diversi e non possono essere attivati simultaneamente. Gli alias sono anch'essi associati allo stesso dispositivo hardware fisico, ma possono essere attivati in simultanea. Per conoscere i dettagli relativi alla creazione di alias per i dispositivi, consultate Sezione 11, Alias per dispositivi. I profili possono servire a creare diversi set di configurazione per diverse reti. Un set di configurazione può comprendere dispositivi logici, host e impostazioni DNS. Dopo aver configurato i profili, potrete usare il Tool di gestione della rete per passare da un profilo all'altro. Per default, esiste un profilo chiamato Common. Per creare un nuovo profilo, fate clic sul pulsante Profilo => Nuovo dal menù a tendina, ed inserite un nome unico per il profilo. State modificando ora il nuovo profilo come indicato dalla barra dello stato nella parte inferiore della finestra principale. Fate clic su di un dispositivo giá esistente nell'elenco, e premete il pulsante Copia per copiare il dispositivo esistente su di un dispositovo logico esistente. Se utilizzate il pulsante Nuovo, viene creato un alias di rete e questa procedura non è corretta. Per cambiare le proprietá del dispositivo logico, selezionatelo dall'elenco e fate clic su Modifica. Per esempio, il nickname puó essere cambiato in un nome piú descrittivo, come ad esempio eth0_office, in modo tale da poter essere riconosciuto piú facilmente. Nell'elenco dei dispositivi, vi è una colonna di caselline etichettata come Profile. Per ciascun profilo, potete togliere o mettere una spunta accanto ai vari dispositivi. Solo i dispositivi spuntati vengono inclusi nel profilo attualmente selezionato. Per esempio, se create un dispositivo logico chiamato eth0_office in un profilo chiamato Office e volete attivare il dispositivo logico se il profilo é selezionato, non selezionate il dispositivo eth0 e selezionate il dispositivo eth0_office. Per esempio, la Figura 2.16, Profilo Office mostra un profilo chiamato Office con il dispositivo logico eth0_office. La configurazione prevede che sia attivata la prima scheda Ethernet tramite DHCP. 35

43 10. Lavorare con i profili Figura Profilo Office Da notare che il profilo Home mostrato nella Figura 2.17, Profilo Home attiva il dispositivo logico eth0_home, il quale è associato con eth0. 36

44 10. Lavorare con i profili Figura Profilo Home Potete anche configurare eth0 in modo che si attivi solo nel profilo Office e che attivi solo un dispositivo PPP (modem) nel profilo Home. Oppure è possibile fare in modo che il profilo Common attivi eth0 e che un profilo Away attivi un dispositivo PPP da usare in viaggio. Per attivare un dispositivo al momento dell'avvio, modificare il file di configurazione del boot loader, in modo da includere l'opzione netprofile=<profilename>. Per esempio, se il sistema usa GRUB come boot loader e /boot/grub/grub.conf contiene: title Red Hat Enterprise Linux ( EL) root (hd0,0) kernel /vmlinuz el ro root=/dev/volgroup00 Modificatelo in modo seguente (dove <profilename> è il nome del profilo da attivare al momento dell'avvio): title Red Hat Enterprise Linux ( EL) root (hd0,0) kernel /vmlinuz el ro root=/dev/volgroup00 Per cambiare i profili dopo aver avviato il sistema, andate su Applications (the main menu on the panel) => Tool del sistema => Controllo dispositivo di rete (oppure digitare il comando 37

45 11. Alias per dispositivi redhat-control-network) per selezionare e attivare un profilo. La sezione attiva profilo appare solo nell'interfaccia Controllo dispositivo di rete se esistono altre interfacce Common. Alternativamente, eseguire il seguente comando per abilitare un profilo (sostituire <profilename> con il nome del profilo): system-config-network-cmd --profile <profilename> --activate 11. Alias per dispositivi Gli Alias per dispositivi sono dispositivi virtuali associati allo stesso hardware fisico, ma possono essere attivati simultaneamente in modo da possedere diversi indirizzi IP. Vengono spesso rappresentati con il nome del dispositivo seguito dai due punti e da un numero (per esempio, eth0:1). Sono utili se desiderate avere più di un indirizzo IP per un singolo sistema che abbia una sola scheda di rete. Dopo aver configurato il dispositivo Ethernet per esempio eth0 per poter usare un indirizzo IP statico (DHCP non funziona con gli alias), andate sulla scheda Dispositivi e selezionate Nuovo. Selezionate la scheda Ethernet da configurare con un alias, impostare l'indirizzo IP per l'alias, e fate clic su Applica per crearlo. Poichè è già esistente un dispositivo per la scheda Ethernet, quello appena creato è l'alias, esempio eth0:1. Attenzione! Se state configurando l'alias di un dispositivo Ethernet, sappiate che non potete impostare né il dispositivo né l'alias in modo che utilizzino DHCP. Dovete configurare l'indirizzo IP manualmente. Figura 2.18, Esempio di alias per dispositivi di rete mostra un esempio di un alias per il dispositivo eth0. Osservate il dispositivo eth0:1 il primo alias per eth0. Il secondo alias per eth0 avrá il nome del dispositivo eth0:2, e cosí via. Per modificare le impostazioni relative all'alias del dispositivo, per esempio, il numero di alias o l'eventuale attivazione all'avvio, selezionatelo dall'elenco e fate clic sul pulsante Modifica. 38

46 12. Salvare e ripristinare la configurazione della rete Figura Esempio di alias per dispositivi di rete Selezionate l'alias e fate clic sul pulsante Activate per attivarlo. Se avete configurato molteplici profili, scegliete in quali profili includere l'alias. Per verificare che l'attivazione dell'alias sia avvenuta correttamente, servitevi del comando / sbin/ifconfig. L'output fornito dal comando dovrebbe mostrare il dispositivo e il relativo alias con indirizzo IP diverso: eth0 Link encap:ethernet HWaddr 00:A0:CC:60:B7:G4 inet addr: Bcast: Mask: Salvare e ripristinare la configurazione della rete La versione della linea di comando di Tool di gestione della rete, può essere usata per salvare su di un file la configurazione di rete del sistema. A sua volta questo file può essere usato per ripristinare l'impostazione della rete su di un sistema Red Hat Enterprise Linux. 39

47 12. Salvare e ripristinare la configurazione della rete Questa caratteristica può essere usata come parte di uno script di back up automatizzato, per salvare la configurazione prima di eseguire un miglioramento o una reinstallazione, o per copiare la configurazione su di un sistema Red Hat Enterprise Linux diverso. Per salvare o esportare la configurazione di rete di un sistema sul file /tmp/network-config, eseguire il seguente comando come utente root: system-config-network-cmd -e > /tmp/network-config Per ripristinare o importare la configurazione della rete dal file creato dal comando precedente, eseguire il seguente comando come un utente root: system-config-network-cmd -i -c -f /tmp/network-config L'opzione -i implica l'importazione dei dati, l'opzione -c implica la cancellazione della configurazione esistente prima di eseguire l'importazione, e l'opzione -f specifica il file da importare. 40

48 Capitolo 3. BIND (Berkeley Internet Name Domain) Nella maggior parte di reti moderne, incluso Internet, gli utenti identificano gli altri computer dal nome. Ció consente all'utente di non ricordare l'indirizzo di rete numerico delle risorse della rete. Il modo migliore per configurare una rete in modo da abilitare i collegamenti basati sul nome, è quello di impostare un Domain Name Service (DNS) o un nameserver, che converte gli hostname sulla rete in indirizzi numerici e viceversa. In questo capitolo verrà trattato il nameserver presente in Red Hat Enterprise Linux, il server DNS Berkeley Internet Name Domain (BIND), con risalto alla struttura dei suoi file di configurazione e il modo in cui può essere amministrato in modo locale o remoto. Nota bene BIND è anche conosciuto come il servizio inamed in Red Hat Enterprise Linux. Potrete gestirlo tramite il Tool di configurazione dei servizi (system-config-service). 1. Introduzione a DNS DNS associa gli hostname con i rispettivi indirizzi IP, in modo tale che quando gli utenti desiderano collegarsi alle altre macchine presenti sulla rete, essi possono far riferimento ai rispettivi nomi senza dover ricordare gli indirizzi IP. L'uso di FQDN e DNS, è vantaggioso per gli amministratori di sistema, perchè consente una certa flessibilità nella modifica degli indirizzi IP per un host, senza influire sulle interrogazioni basate sui nomi dei computer stessi. Gli amministratori inoltre possono stabilire quale computer gestisce una interrogazione basata sui nomi. Il DNS, viene normalmente implementato utilizzando server centrali che risultano "autorevoli" per alcuni domini e si rivolgono ad altri server DNS per ottenere le informazioni di cui non dispongono. Quando un host client richiede informazioni al server dei nomi, di solito esso si collega tramite la porta 53 del server. Il server dei nomi cerca di risolvere l'fqdn in base alla sua libreria di conversione, che può contenere informazioni autorevoli sull'host richiesto oppure dati memorizzati in seguito a una precedente query. Se la libreria di conversione del server dei nomi non contiene già la risposta, esso si rivolgerà ad altri server di nomi, chiamati server dei nomi root per determinare quali sono i server di nomi autorevoli per l'fqdn in questione. Successivamente con queste informazioni, interrogherà i server dei nomi autorevoli per determinare l'indirizzo IP dell'host richiesto. Se invece si esegue una ricerca inversa, viene utilizzata la stessa procedura, ma la richiesta viene inoltrata con un indirizzo IP sconosciuto anzichè un nome Zone del server dei nomi 41

49 1.2. Tipi di server dei nomi Su internet, l'fqdn di un host può essere suddiviso in sezioni diverse, organizzate in una gerarchia (ad albero) con un tronco, dei rami principali, dei rami secondari e così via. Considerate il seguente FQDN: bob.sales.example.com Per capire come l'fqdn venga convertito per trovare l'indirizzo IP che si riferisce a un determinato sistema, è necessario leggere il nome da destra a sinistra, con ogni livello della gerarchia separato da punti (.). In questo esempio, com indica il dominio del livello superiore per questo FQDN. Il nome example indica un sottodominio di com e a sua volta, sales è un sottodominio di example. L'ultimo nome a sinistra in un FQDN, bob, è l'hostname della macchina specifica. A eccezione dell'hostname, ogni sezione è definita zona, e contraddistingue un particolare spazio dei nomi. Tale spazio controlla la denominazione dei sottodomini alla propria sinistra. Mentre in questo esempio sono contenuti solo due sottodomini, un FQDN deve contenerne almeno uno, ma può comprenderne molti di più, a seconda di come sono organizzati gli spazi dei nomi. Le zone sono definite nei server dei nomi autorevoli mediante l'uso di file di zona, (che descrivono lo spazio dei nomi di quella zona), ed i server di posta da usare per un dominio o sottodominio particolare. I file di zona sono memorizzati in server dei nomi primari (chiamati anche server dei nomi master) che sono autorevoli e consentono la modifica dei file, e nei server dei nomi secondari (chiamati anche server dei nomi slave), che ricevono i propri file di zona dai server dei nomi primari. Ogni server dei nomi può essere allo stesso tempo primario o secondario per zone diverse e può essere riconosciuto autorevole per più zone. Dipende tutto dalla configurazione del server dei nomi Tipi di server dei nomi Esistono quattro tipi principali di configurazione per i server dei nomi: master Memorizza informazioni sulla zona originale e autorevole per uno spazio dei nomi, e risponde alle richieste inerenti al suddetto spazio provenienti da altri server dei nomi. slave Risponde a richieste di altri server dei nomi relative agli spazi dei nomi sui quali ha autorità. Tuttavia i server dei nomi slave ottengono le informazioni sugli spazi dei nomi dai server dei nomi master. caching-only Offre i servizi di risoluzione name-to-ip ma non è autorevole per tutte le zone. Di norma, le risposte a tutte le risoluzioni vengono memorizzate nella cache per un determinato periodo di tempo, solitamente specificato dal record di zona recuperato. forwarding Inoltra richieste ad un elenco specifico di server dei nomi per la risoluzione dei nomi. Se nessuno dei server specificati può eseguire la risoluzione, il processo si interrompe e la risoluzione non viene completata. Un server dei nomi può essere di uno o più tipi tra quelli descritti. Per esempio può essere un master per alcune zone e uno slave per altre e può offrire solo una risoluzione forwarding. 42

50 2. /etc/named.conf 1.3. BIND come un server dei nomi BIND effettua dei servizi di risoluzione del nome, attraverso il demone /usr/sbin/named. BIND include anche una utility di gestione chiamata /usr/sbin/rndc. Maggiori informazioni su rndc sono disponibili nelsezione 4, Uso di rndc. BIND conserva i propri file di configurazione nelle seguenti posizioni: /etc/named.conf Il file di configurazione per il demone named directory /var/named/ La directory named dove si trovano i file di zona, statistici, e della cache Nota bene Se avete installato il pacchetto bind-chroot, il servizio BIND verrà eseguito nell'ambiente /var/named/chroot. Tutti i file di configurazione verranno spostati nel suo interno. Per questo named.conf si troverà in /var/named/chroot/etc/named.conf e così via. Suggerimento Se avete installato il pacchetto caching-nameserver, il file di configurazione di default è /etc/named.caching-nameserver.conf. Per annullare questa configurazione di default, sarà possibile creare il proprio file di configurazione personalizzato in / etc/named.conf. BIND userà il file personalizzato /etc/named.conf invece del file di configurazione di default dopo il riavvio. Le sezioni successive descrivono in dettaglio i file di configurazione BIND. 2. /etc/named.conf Il file named.conf è un insieme di istruzioni che utilizza opzioni nidificate tra parentesi graffe { }. Gli amministratori devono prestare attenzione nel modificare named.conf, in quanto piccoli errori di sintassi impediscono la partenza del servizio named. Un file tipico named.conf é organizzato in modo del tutto simile al seguente esempio: <statement-1> ["<statement-1-name>"] [<statement-1-class>] { <option-1>; <option-2>; <option-n>; }; <statem 2.1. Tipo di istruzioni comuni Le seguenti istruzioni vengono utilizzate comunemente in /etc/named.conf: 43

51 2.1. Tipo di istruzioni comuni Istruzioni acl L'istruzione acl (o commento di controllo di accesso) definisce il gruppo o gli host permessi o meno all'accesso al server dei nomi. Una istruzione acl ha la seguente forma: acl <acl-name> { <match-element>; [<match-element>;...] }; In questa istruzione, sostituire <acl-nome> con il nome della lista di controllo accesso e sostituire <elemento-corrispondente> con una serie di indirizzi IP separati da un punto e virgola. La maggior parte delle volte vengono utilizzati gli indirizzi IP individuali o le notazioni di rete IP (come /24) per identificare gli indirizzi IP all'interno del commento acl. Le seguenti liste di controllo per gli accessi sono giá definite come parole chiavi per semplificare la configurazione: any Corrisponde ad ogni indirizzo IP localhost Corrisponde a qualsiasi indirizzo IP in uso nel sistema locale. localnets Corrisponde a qualsiasi indirizzo IP in qualsiasi rete a cui il sistema locale è connesso. none Non corrisponde ad alcun indirizzo IP. Se utilizzato con altre istruzioni (come ad esempio options), i commenti acl possono essere molto utili nel prevenire l'uso improprio di un server dei nomi BIND. Il seguente esempio definisce due liste di controllo di accesso e usa una istruzione options per definire come vengono trattate dal server: acl black-hats { /24; /24; }; acl red-hats { /24; }; options { blackhole { black Questo esempio contiene due elenchi di controllo per l'accesso, black-hats e red-hats. Gli host nell'elenco black-hats non vengono accettati nel server dei nomi, mentre vengono accettati nell'elenco red-hats L'istruzione include L'istruzione include permette ai file di essere inclusi in un file named.conf. In questo modo i dati importanti di configurazione (come ad esempio keys), possono essere posizionati in un file separato con permessi restrittivi. Una istruzione include assume la seguente forma: include "<file-name>" In questa istruzione, <nome-file> viene sostituito con un path assoluto per un file Istruzione options L'istruzione options definisce le opzioni di configurazione globale del server e imposta i default 44

52 2.1. Tipo di istruzioni comuni per altri commenti. Puó essere usato per specificare la posizione della directory di lavoro named i tipi di interrogazione permessi e molto altro. L'istruzione options assume la seguente forma: options { <option>; [<option>;...] }; In questa istruzione, le direttive <option> sono sostituite con una opzione valida. Le seguenti sono opzioni usate comunemente: allow-query Specifica gli host autorizzati ad interrogare questo server dei nomi. Per default, tutti gli host sono autorizzati all'interrogazione. Un access control list o un insieme di indirizzi o reti IP, può essere utilizzato solo per autorizzare host particolari a interrogare il server dei nomi. allow-recursion Simile a allow-query, questa opzione viene applicata alle interrogazioni ricorsive. Per default, tutti gli host sono autorizzati ad effettuare richieste ricorsive ai server dei nomi. blackhole Specifica quali host non possono interrogare il server. directory Specifica la directory di lavoro named se diversa dal valore di default /var/named/. forwarders Specifica un elenco di indirizzi IP validi per i server dei nomi a cui inoltrare le richieste di risoluzione. forward Specifica il modo in cui avviene l'inoltro da parte di una direttiva forwarders. Sono accettate le seguenti opzioni: first Specifica che i nameserver elencati nella direttiva forwarders vengano interrogati prima che named tenti di risolvere il nome da solo. only Specifica che named non tenta di eseguire la risoluzione del nome da solo, nel caso in cui le interrogazioni ai nameserver specificati nella direttiva forwarders falliscano. listen-on Specifica l'interfaccia di rete che named utilizza per ricevere le interrogazioni. Per default, vengono utilizzate tutte le interfacce. Usando questa direttiva su di un server DNS, il quale funge da gateway, BIND puó essere configurato in modo da rispondere solo alle domande originate da una delle reti. Il seguente è un esempio di direttiva listen-on: options { listen-on { ; }; }; 45

53 2.1. Tipo di istruzioni comuni In questo esempio, vengono accettate solo le richieste che provengono dall'interfaccia di rete che serve la rete privata ( ). notify Controlla se named notifica ai server slave quando si aggiorna una zona. Accetta le seguenti opzioni: yes Notifica i server slave. no Non notifica i server slave. explicit Notifica solo i server slave specificati in un elenco also-notify all'interno di una istruzione di zona. pid-file Specifica la posizione del file ID di processo creato da named. root-delegation-only Abilita la forzatura delle proprietà di delega nei top-level domains (TLD), e nelle zone root con un elenco di esclusione opzionale. Delega è quel processo di separazione di una singola zona in sottozone multiple. Per poter creare una zona delegata, vengono usati gli oggetti conosciuti come record NS. I record NameServer (record di delega) annunciano i nameserver principali per una zona particolare. L'esempio root-delegation-only seguente, specifica un elenco di esclusione di TLD, dai quali si prevedono delle risposte non delegate fidate: options { root-delegation-only exclude { "ad"; "ar"; "biz"; "cr"; "cu"; "de"; "dm"; "id"; "lu"; "lv"; " statistics-file Specifica una posizione alternativa per i file delle statistiche. Per default, le statistiche di named vengono salvate nel file /var/named/named.stats. Sono inoltre disponibili decine di altre opzioni, molte delle quali dipendono l'una dall'altra per poter funzionare correttamente. Per maggiori informazioni, consultate il Manuale BIND 9 di riferimento per l'amministratore nelsezione 7.1, Documentazione installata e la pagina man per bind.conf per maggiori informazioni Istruzione zone Una istruzione zone definisce le caratteristiche di una zona come ad esempio la posizione dei propri file di configurazione e le opzioni specifiche di zona. Questa istruzione puó essere usata per sovrascrivere le istruzioni globali options. Una istruzione zone assume la seguente forma: zone <zone-name><zone-class> { <zone-options>; [<zone-options>;...] }; In questa istruzione, <nome-zona> é il nome della zona, <classe-zona> é la zona facoltativa della zona, e <opzioni-zona> é un elenco di opzioni che caratterizzano la zona. L'attributo <nome-zona> per l'istruzione della zona, é particolarmente importante. Esso è il valore 46

54 2.1. Tipo di istruzioni comuni di default assegnato per la direttiva $ORIGIN, usata all'interno delfile zone corrispondente posizionato nella directory /var/named/. Il demone named conferisce il nome della zona a qualsiasi nome del dominio non qualificato elencato nel file zone. Nota bene Se avete installato il pacchetto caching-nameserver, il file di configurazione di default risulterà essere all'interno di /etc/named.rfc1912.zones. Per esempio, se una istruzione zone definisce lo spazio del nome per example.com, usare example.com come <zone-name> cosí da posizionarlo alla fine dell'hostname all'interno del file zone example.com. Per maggiori informazioni sui file di zona, consultate Sezione 3, File zone. Le opzioni piú comuni della zone include quanto segue: allow-query Specifica i client abilitati a richiedere informazioni inerenti questa zona. Per default tutte le richieste vengono permesse. allow-transfer Specifica i server slave abilitati a richiedere un trasferimento delle informazioni della zona. Il default é di permettere tutte le richieste di trasferimento. allow-update Specifica gli host che sono abilitati ad aggiornare dinamicamente le informazioni nella loro zona. Il default é di negare tutte le richieste di aggiornamento dinamico. Fare attenzione a permettere agli host di aggiornare le informazioni inerenti le loro zone. Non abilitate questa funzione se l'utente non é fidato. In generale, é meglio avere un amministratore che aggiorni manualmente le informazioni e ricaricare il servizio named. file Specifica il nome del file nella directory di lavoro named che contiene i dati di configurazione della zona. masters Specifica gli indirizzi IP dai quali si effettua la richiesta di informazioni della zona autoritaria, usato solo se la zona é definita come type eslave. notify Specifica se named effettua la notifica ai server slave quando si aggiorna una zona. Questa direttiva accetta le seguenti opzioni: yes Notifica i server slave. no Non notifica i server slave. explicit Notifica solo i server slave specificati in un elenco also-notify all'interno di 47

55 2.1. Tipo di istruzioni comuni una istruzione di zona. type Definisce il tipo di zona. Di seguito viene riportata una lista di opzioni valide: delegation-only Forza lo stato di delega delle zone dell'infrastruttura, come ad esempio COM, NET oppure ORG. Qualsiasi risposta ricevuta senza una delega implicita o esplicita, viene trattata come NXDOMAIN. Questa opzione viene applicata solo in TLD, o nelle zone root utilizzate con implementazioni caching o ricorsive. forward Inoltra tutte le richieste di informazioni di una zona in particolare ad altri server dei nomi. hint tipo speciale di zona usato per fare riferimento ai server dei nomi root, utilizzati per risolvere richieste quando una zona è sconosciuta. In genere non è necessario configurare una zona del tipo hint. master Definisce il server dei nomi autorevole per questa zona. Occorre impostare una zona del tipo master se nel vostro sistema vi sono i file di configurazione della zona. slave Definisce il server come slave per questa zona. Specifica anche l'indirizzo IP del server dei nomi per la zona. zone-statistics Configura named in modo da conservare le statistiche relative a questa zona, scrivendole nella posizione di default (/var/named/named.stats), o nel file elencato nell'opzione statistics-file nell'istruzione server. Consultate Sezione 2.2, Altri tipi di istruzione per maggiori informazioni riguardanti l'istruzione server Istruzione zone: esempi La maggior parte delle modifiche al file /etc/named.conf di un server dei nomi master o slave riguarda l'aggiunta, la modifica o la cancellazione di istruzioni zone. Sebbene queste istruzioni zone possano contenere molte opzioni, quasi tutti i server dei nomi ne usano solo alcune. I commenti zone che seguono sono alcuni esempi di base da utilizzare in una relazione master/slave. Quello riportato di seguito è un esempio di istruzione zone per il server dei nomi primario con dominio example.com ( ): zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; }; All'interno dell'istruzione la zona è identificata come example.com, il tipo è impostato su master e il servizio named legge il file /var/named/example.com.zone. Indica inoltre a named di non consentire l'aggiornamento da parte di nessun altro host. Una istruzione zone di un server slave per example.com è leggermente diverso dall'esempio precedente. Per un server slave il tipo è impostato su slave e invece della riga allow-update è presente una direttiva che indica a named l'indirizzo IP del server master. Quello riportato di seguito è un esempio di istruzione zonedel server slave, per la zona exam- 48

56 2.2. Altri tipi di istruzione ple.com: zone "example.com" { type slave; file "example.com.zone"; masters { ; }; }; Questa istruzione zone configuranamed sul server slave, in modo da interrogare il server master all'indirizzo IP , per informazioni riguardanti la zona example.com. Le informazioni che il server slave riceve dal server master vengono salvate in /var/named/example.com.zone Altri tipi di istruzione Ecco riportata una lista di istruzioni meno usate, disponibili in named.conf controls Configura vari requisiti di sicurezza necessari all'uso del comando rndc per amministrare il servizio named. Consultate Sezione 4.1, Configurazione di /etc/named.conf per saperne di più su come è strutturata l'istruzione controls, incluso le opzioni disponibili. key "<key-name>" Definisce una chiave particolare a seconda del nome. Le chiavi sono usate per autenticare azioni varie, come ad esempio aggiornamenti sicuri o l'uso del comando rndc. Con key vengono utilizzate due opzioni: algorithm <algorithm-name> Il tipo di algoritmo usato, come ad esempio dsa o hmacmd5. secret "<key-value>" La chive cifrata. Consultate Sezione 4.2, Configurazione di /etc/rndc.conf per informazioni su come scrivere una istruzione key. logging Permette l'uso di tipi multipli di log chiamati canali. Usando l'opzione channel all'interno dell'istruzione logging, un tipo di log personalizzato può essere creato con il proprio nome del file (file), misura limite (size), versione (version), e livello d'importanza (severity). Una volta definito un canale personalizzato, una opzione category viene usata per categorizzare il canale e iniziare il logging quando si avvia named. Per default, named effettua una registrazione di messaggi standard per il demone syslog, inviandoli in /var/log/messages. Ció accade perché diversi canali standard sono stati creati in BIND con diversi livelli di severitá, come ad esempio default_syslog (il quale gestisce i messaggi di logging), e default_debug (il quale gestisce solo i messaggi di debug). Una categoria di default, chiamatadefault, usa i canali interni per effettuare un logging normale senza alcuna configurazione speciale. Personalizzare un processo di log in puó rappresentare un una fase molto articolata, e và oltre lo scopo di questo capitolo. Per maggiori informazioni sulla creazione dei log BIND personalizzati, consultare BIND 9 Administrator Reference Manual nelsezione 7.1, Documentazione installata. server 49

57 2.3. Tag di commento Specifica le opzioni che influenzano il comportamento di named rispetto ai server dei nomi remoti, in particolar modo nei confronti delle notifiche e dei trasferimenti di zona. L'opzione transfer-format controlla se una risorsa record viene inviata con ogni messaggio (one-answer) oppure se vengono inviate risorse record multiple sono inviate con ogni messaggio (many-answers). Mentre many-answers é piú efficiete, solo i server dei nomi BIND piú recenti lo possono comprendere. trusted-keys Contiene diverse chiavi pubbliche usate per rendere sicuro DNS (DNSSEC). Consultare Sezione 5.3, Sicurezza per maggiori informazioni sulla sicurezza di BIND. view "<view-name>" Crea una visuale speciale a seconda della rete sulla quale viene effettuata l'interrogazione da parte dell'host al server dei nomi.questo permette ad alcuni host di ricevere una risposta riguardante una zona particolare, mentre altri host riceveranno delle informazioni totalmente diverse. Alternativamente, alcune zone vengono rese disponibili ad alcuni host sicuri mentre quelli non sicuri possono solo effettuare delle richieste ad altre zone. Visuali multiple possono essere usate fino a quando i nomi sono unici. L'opzione matchclients specifica gli indirizzi IP idonei ad una visuale particolare. Qualsiasi istruzione options puó essere usata all'interno di una visuale, sovrascrivendo le opzioni globali giá configurate per named. Molti commenti view contengono istruzioni multiple zone idonee all'elenco match-clients. L'ordine con il quale le istruzioni view vengono elencate é molto importante, poichè verrà utilizzata la prima istruzione view idonea ad un particolare indirizzo IP del client. Consultate Sezione 5.2, Visualizzazioni multiple per maggiori informazioni sull'istruzione view Tag di commento Il seguente é un elenco di tag di commento validi usati all'interno di named.conf: // Quando posizionato all'inizio di una riga, la stessa viene ignorata da named. # Quando posizionato all'inizio di una riga, la stessa viene ignorata da named. /* e */ Quando il testo viene contenuto in queste etichette, lo stesso viene ignorato da named. 3. File zone I file di zona, contenenti le informazioni relative a un determinato spazio dei nomi, sono memorizzati nella directory operativa di named, (/var/named) per default. Ogni file di zona viene nominato a seconda dei dati indicati nell'opzione file contenuta nell'istruzione zone. In genere si riferisce al dominio in questione e identifica il file in quanto contiene dati sulla zona, come per esempio example.com.zone. 50

58 3.1. Direttive dei file zone Nota bene Se avete installato il pacchetto bind-chroot, il servizio BIND verrà eseguito nell'ambiente /var/named/chroot. Tutti i file di configurazione verranno spostati nel suo interno. Per questo è possibile trovare i file di zona all'interno di / var/named/chroot/var/named. Ogni file zone può contenere direttive e dei record della risorsa. Le direttive indicano al server dei nomi di eseguire una certa azione o di eseguire delle impostazioni speciali per la zona. I record della risorsa definiscono i parametri della zona attribuendo una identità a host individuali. Le direttive sono facoltative, mentre i record della risorsa sono necessari per fornire il servizio dei nomi a quella zona. Tutte le direttive ed i record dovrebbero essere inseriti su righe diverse. Nei file zone è possibile aggiungere dei commenti dopo il carattere punto e virgola (;) Direttive dei file zone Le direttive sono contraddistinte dal carattere ($) che precede il nome della direttiva e che di solito si trova all'inizio del file zone. Le direttive più usate sono le seguenti: $INCLUDE Indica a named di includere un file di zona in un altro file nel punto in cui viene usata la direttiva. Ciò consente di memorizzare impostazioni di zona aggiuntive separatamente dal file di zona principale. $ORIGIN Imposta il nome del dominio da accodare a qualsiasi record non qualificato, come quelli che specificano solo l'host e nient'altro. Per esempio, un file zone potrebbe contenere una riga seguente: $ORIGIN example.com. Qualsiasi nome utilizzato nei record della risorsa, che non terminacon un punto (.), presenterá example.com. Nota bene Non è necessario usare la direttiva $ORIGIN se alla zona si assegna un nome nel file /etc/named.conf, poichè il nome della zona viene utilizzato, per default, come valore della direttiva $ORIGIN. 51

59 3.2. Informazioni sulla risorsa del file zone $TTL Imposta il valore predefinito Time to Live (TTL) per la zona. Si tratta di un valore, in secondi, assegnato ai server dei nomi che indica il periodo di validità dei record di risorsa della zona. Un record di risorsa può avere un valore TTL proprio, che annulla quindi quello impostato da questa direttiva. Impostando un valore più alto si indica ai server dei nomi di conservare in memoria queste informazioni di zona per un periodo di tempo maggiore. Ciò riduce il numero di richieste relative a questa zona, ma allunga anche il tempo necessario per modificare il record di risorse Informazioni sulla risorsa del file zone Il componente primario di un file zone risulta essere il proprio record di risorsa. Sono disponibili diversi record della risorsa del file zone. I seguenti tipi sono tra i più usati: A Informazioni sull'indirizzo che specifica un indirizzo IP da assegnare al nome, come in questo esempio: <host> IN A <IP-address> Se non viene indicato il valore <host>, il record A fa riferimento a un indirizzo IP predefinito per l'inizio dello spazio dei nomi. Questo sistema è utilizzato per tutte le richieste non FQDN. Prendete in considerazione i seguenti esempi di record A per il file zone example.com: server1 IN A IN A Le richieste per example.com vengono indirizzate a o CNAME Ciò si riferisce al record del Canonical Nameil quale mappa un nome all'altro. Questo tipo di record è conosciuto anche come un alias record. L'esempio successivo indica a named che le richieste inviate a <nome-alias> dovrebbero indicare l'host <nome-reale>. I record CNAME sono utilizzati più comunemente per indicare i servizi che utilizzano uno schema di assegnazione dei nomi comune,come ad esempio www per i Web server. <alias-name> IN CNAME <real-name> Considerate l'esempio riportato di seguito, in cui il record A lega un indirizzo IP con un hostname, mentre il record CNAME indica l'hostname www più usato. server1 IN A www IN CNAME server1 MX Ciò si riferisce al record Mail exchange il quale indica dove inviare la posta riferita ad uno spazio del nome controllato da questa zona. 52

60 3.2. Informazioni sulla risorsa del file zone IN MX <preference-value>< -server-name> Di seguito <valore-preferenza> vi consente di classificare numericamente i server per uno spazio dei nomi, dando la precedenza ad alcuni sistemi rispetto ad altri. Il record di risorsa MX con il <valore-preferenza> più basso, ha la precedenza sugli altri. Tuttavia server multipli possono presentare lo stesso valore e distribuire quindi il traffico di posta. Il <nome-server- > può essere un nome host o un FQDN. IN MX 10 mail.example.com. IN MX 20 mail2.example.com. In questo esempio il primo server di posta mail.example.com ha la precedenza sul server mail2.example.com al momento della ricezione di posta per il dominio example.com. NS Ciò si riferisce al record NameServer che annuncia i server dei nomi autorevoli per una determinata zona. Quanto segue illustra la struttura di un record NS: IN NS <nameserver-name> Qui il <nome-nameserver> dovrebbe essere un FQDN. Di seguito sono elencati due nomi di server come autorevoli per un dominio. Non importa se questi server dei nomi sono slave o master, poiché entrambi sono considerati autorevoli. IN NS dns1.example.com. IN NS dns2.example.com. PTR Ciò si riferisce al record PoinTeR che serve per fare riferimento ad un'altra porzione dello spazio dei nomi. I record PTR vengono usati principalmente per invertire la risoluzione del nome, in quanto essi si riferiscono agli indirizzi IP ad un particolare nome. Per maggiori esempi sui record PTR in uso, consultate Sezione 3.4, File zone per la risoluzione inversa dei nomi. SOA Si riferisce al record della risorsa Start Of Authority, il quale indica al server dei nomi le informazioni autorevoli importanti inerenti lo spazio dei nomi per il nameserver. Posizionato dopo le direttive, SOA è il primo record di risorsa in un file zone. Quanto segue mostra la struttura di base di un record di IN SOA <primary-name-server><hostmaster- > ( <serial-number><time-to-refresh><time-to-retry><time Il serve a posizionare la direttiva $ORIGIN (o il nome della zona, se la direttiva non è impostata) come il namespace definito da questo record di risorsa SOA. L'hostname del server dei nomi primario il quale è autoritario per questo dominio, è la direttiva <primary-name-server> e l' della persona da contattare per questo namespace, è la direttiva <hostmaster- >. 53

61 3.3. Esempi di file zone La direttiva <numero-seriale> è un valore numerico incrementato ogni volta il file zone viene modificato, affinche named riceva l'informazione di ricaricare la zona. La direttiva <tempo-di-aggiornamento> è un server slave del valore numerico usato per determinare il tempo necessario prima di chiedere al server dei nomi master se sono state effettuate delle modifiche alla zona. La direttiva <numero-seriale> è un valore numerico utilizzato dai server slave per determinare se sta usando dati di zona obsoleti e deve dunque aggiornarli. La direttiva <time-to-retry> è un valore numerico usato dai server slave per determinare il periodo di tempo di attesa, prima di formulare una richiesta di aggiornamento se il server dei nomi non risponde. Se il master non ha risposto alla richiesta di aggiornamento entro il periodo di tempo specificato in <time-to- expire>, i server slave cessano di fungere come autorità per quanto riguarda quel determinato spazio dei nomi. La direttiva <TTL-minimo> rappresenta l'ammontare di tempo utilizzato dagli altri server dei nomi per memorizzare le informazioni della zona. Quando si configura BIND, il tempo viene riportato in secondi. Tuttavia potete utilizzare anche delle abbreviazioni per altre unità di tempo, come minuti (M), ore (H), giorni (D) e settimane (W). La Tabella 3.1, Secondi paragonati ad altre unità di tempo mostra la quantità di tempo in secondi e l'equivalente in un altro formato. Secondi Altre unità di tempo 60 1M M H H H H D D W D Tabella 3.1. Secondi paragonati ad altre unità di tempo L'esempio seguente mostra la struttura che un record di risorsa SOA potrebbe avere quando popolato con valori IN SOA dns1.example.com. hostmaster.example.com. ( ; serial ; refresh after 6 hours 3.3. Esempi di file zone Le direttive e i record di risorsa, visti individualmente, possono essere difficili da comprendere. 54

62 3.4. File zone per la risoluzione inversa dei nomi Comunque, tutto ha molto più senso se riunito in un unico file. Il seguente esempio mostra un file zone di base. $ORIGIN example.com. $TTL IN SOA dns1.example.com. hostmaster.example.com. ( ; serial 21 In questo esempio vengono utilizzate le direttive standard e i valori SOA. I server dei nomi autorevoli sono impostati come dns1.example.com e dns2.example.com, con il record A che li lega rispettivamente a e Il server di posta configurato con i record MX fa riferimento a server1 e server2 tramite CNAME. Poiché i nomi del server1 e del server2 non terminano con un punto (.), il dominio $ORIGIN viene collocato dopo tali nomi, diventando server1.example.com e server2.example.com. È possibile determinarne gli indirizzi IP tramite i relativi record di risorsa A. I servizi FTP e Web, disponibili con i nomi standard ftp.example.com e vengono indirizzati a macchine che forniscono i servizi adeguati per questi nomi usando i record CNAME. Questo file di zona viene utilizzato con l'istruzione zone nel file named.conf simile a quello riportato qui di seguito: zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; }; 3.4. File zone per la risoluzione inversa dei nomi Un file di zona per la risoluzione inversa dei nomi viene utilizzato per tradurre un indirizzo IP in uno spazio dei nomi particolare in un FQDN. Somiglia molto ad un file di zona standard, ad eccezione per il fatto che i record di risorsa PTR, vengono utilizzati per collegare gli indirizzi IP ad un nome del dominio qualificato. L'esempio riportato mostra la struttura di un record PTR: <last-ip-digit> IN PTR <FQDN-of-system> <ultima-cifra-ip> si riferisce all'ultimo numero in un indirizzo IP che dovrebbe far riferimento all'fqdn di un determinato sistema. Nell'esempio riportato qui di seguito gli indirizzi IP da a fanno riferimento agli FQDN corrispondenti. Esso è posizionato all'interno di /var/named/example.com.rr.zone. $ORIGIN in-addr.arpa. $TTL IN SOA dns1.example.com. hostmaster.example.com. ( ; s Questo file di zona viene utilizzato con l'istruzione zone nel file named.conf simile a quello riportato qui di seguito: zone " in-addr.arpa" IN { type master; file "example.com.rr.zone"; allow-update { none; }; }; Esiste una differenza davvero minima tra questo esempio e un'istruzione standard zone, salvo per il nome della zona. Una zona per la risoluzione inversa dei nomi richiede che siano invertiti i primi tre blocchi dell'indirizzo IP e che dopo di questi venga aggiunto ".in-addr.arpa". Ciò permette che il blocco singolo di numeri IP utilizzato nel file della zona per la risoluzione inversa dei nomi venga collegato correttamente in questa zona. 55

63 4.1. Configurazione di /etc/named.conf 4. Uso di rndc BIND dispone di una utility chiamata rndc che vi consente di amministrare la linea di comando del demone named da un localhost oppure da un host remoto. Per impedire l'accesso non autorizzato del demone named, BIND usa un metodo di autenticazione a chiave segreta condivisa per garantire i privilegi a determinati host. Ció significa che una chiave identica deve essere presente in entrambi i file di configurazione /etc/named.conf e rndc, /etc/rndc.conf. Nota bene Se avete installato il pacchetto bind-chroot, il servizio BIND verrà eseguito all'interno dell'ambiente /var/named/chroot. Tutti i file di configurazione verrano spostati al suo interno. Per questo, il file rndc.conf si trova all'interno di / var/named/chroot/etc/rndc.conf. Poichè la utility rndc non può essere eseguita in un ambiente chroot, / etc/rndc.conf risulta essere un link simbolico per / var/named/chroot/etc/rndc.conf Configurazione di /etc/named.conf Per consentire a rndc di connettersi al servizio named, è necessario disporre dell'istruzionecontrols nel file /etc/named.conf del server BIND. L'istruzione controls, riportata nel seguente esempio, permette a rndc di collegarsi dal localhost. controls { inet allow { localhost; } keys { <key-name>; }; }; Questa istruzione indica a named di ascoltare sulla porta TCP 953 di default dell'indirizzo di loopback e abilita i comandi rndc provenienti dall'host locale, su corretta indicazione della chiave. Il <nome-chiave> specifica un nome nell'istruzione key all'interno del file /etc/named.conf. L'esempio successivo mostra l'istruzione key. key "<key-name>" { algorithm hmac-md5; secret "<key-value>"; }; In questo caso, il <valore-chiave> usa l'algoritmo MD5. Usate il seguente comando per generare le vostre chiavi usando l'algoritmo HMAC-MD5: dnssec-keygen -a hmac-md5 -b <bit-length> -n HOST <key-file-name> È consigliabile una chiave con una lunghezza minima di 256 bit. La chiave effettiva da inserire nell'area <valore-chiave> si trova nel file <nome-file-chiave> generato da questo comando. 56

64 4.2. Configurazione di /etc/rndc.conf Avvertenza Poichè /etc/named.conf viene letto da tutti, è consigliabile posizionare l'istruzione key in un file separato e leggibile solo da un utente root, per poi usare una istruzione include come riferimento. Per esempio: include "/etc/rndc.key"; 4.2. Configurazione di /etc/rndc.conf key é l'istruzione piú importante contenuta nel file /etc/rndc.conf. key "<key-name>" { algorithm hmac-md5; secret "<key-value>"; }; Il <nome-chiave> e il <valore-chiave> devono avere le stesse impostazioni indicate nel file / etc/named.conf. Per mettere insieme le chiavi specificate nel file /etc/named.conf del server, aggiungere le seguenti righe a /etc/rndc.conf. options { default-server localhost; default-key "<key-name>"; }; Questa direttiva imposta la chiave di default globale. Tuttavia il file di configurazione rndc puó specificare chiavi diverse per server diversi, come nell'esempio riportato: server localhost { key "<key-name>"; }; Importante Assicurarsi che solo un utente root possa leggere o scrivere sul file /etc/rndc.conf. Per maggiori informazioni sul file /etc/rndc.conf, controllare la pagina man di rndc.conf Opzioni della linea di comando Un comando rndc ha la seguente forma: rndc <options><command><command-options> Quando si esegue rndc in un host locale configurato in modo corretto, è possibile utilizzare i seguenti comandi: halt interrompe immediatamente il servizio named. querylog Attiva la registrazione delle richieste effettuate dai client a questo server dei nomi. 57

65 5. BIND: caratteristiche avanzate refresh aggiorna il database del server dei nomi. reload Indica al server dei nomi di ricaricare i file zone, ma di non cancellare tutti i risultati memorizzati in precedenza. Ciò vi consente di effettuare delle modifiche ai file zone senza perdere tutte le risoluzioni di nomi archiviate. Se le modifiche riguardano solo una zona specifica, potete ricaricare solo quella zona aggiungendo il nome della zona dopo il comando reload. stats Trasferisce le attuali statistiche di named nel file /var/named/named.stats. stop Interrompe il server in modo tale da salvare tutti gli aggiornamenti dinamici e i dati Incremental Zone Transfers (IXFR) prima di uscire. Se desiderate annullare le impostazioni predefinite nel file /etc/rndc.conf, sono disponibili le seguenti opzioni: -c <file-configurazione> Specifica la posizione alternata di un file di configurazione. -p <port-number> Specifica il numero di una porta da usare per la connessione rndc, diversa dalla porta 953 predefinita. -s <server> Specifica un server diverso da default-server elencato in /etc/rndc.conf. -y <key-name> Vi consente di specificare una chiave diversa da quella indicata dall'opzione default-key nel file /etc/rndc.conf. Per ulteriori informazioni su queste opzioni, consultate la pagina man di rndc. 5. BIND: caratteristiche avanzate La maggior parte delle versioni di BIND utilizza named per fornire servizi di risoluzione dei nomi o per fungere da autorità per un particolare dominio o sottodominio. Tuttavia la versione 9 di BIND comprende una serie di caratteristiche avanzate che, se opportunamente configurate e utilizzate, garantiscono un servizio DNS più sicuro ed efficiente. Avvertenza Alcuni di questi contenuti, come DNSSEC, TSIG e IXFR (i quali vengono definiti nella seguente sezione), andrebbero usati solo in ambienti di rete con server dei nomi capaci di supportarli. Se l'ambiente di rete comprende i server dei nomi non BIND o versioni BIND precedenti, verificate che ogni contenuto sia supportato prima di usarlo. Tutte le caratteristiche fin qui trattate vengono approfondite nel BIND 9 Administrator Reference Manual nelsezione 7.1, Documentazione installata Miglioramenti del protocollo DNS 58

66 5.2. Visualizzazioni multiple BIND supporta i trasferimenti di zona incrementali (IXFR), grazie ai quali un server dei nomi slave effettua solo il download delle parti aggiornate di una zona modificata su di un server dei nomi master. Il processo di trasferimento standard richiede che l'intera zona venga trasferita a ogni server dei nomi slave, anche per la più piccola modifica. Per domini molto diffusi con file di zona lunghi e numerosi server dei nomi slave, IXFR semplifica i processi di notifica e aggiornamento. IXFR è disponibile solo se utilizzate un aggiornamento dinamico per modificare i record della zona master. Se invece modificate manualmente i file di zona per effettuare delle modifiche, viene utilizzato l'automatic Zone Transfer (AXFR). Per maggiori informazioni sull'aggiornamento dinamico, consultate il BIND 9 Administrator Reference Manual presente in Sezione 7.1, Documentazione installata Visualizzazioni multiple Mediante l'uso dell'istruzione view del file named.conf BIND presenta informazioni diverse a seconda di quale rete effettua la richiesta. Questa opzione è utile soprattutto se desiderate che i client esterni alla vostra rete non possano eseguire un determinato servizio DNS, ma non volete invece escludere i client interni. L'istruzione view utilizza l'opzione match-clients per far corrispondere indirizzi IP o reti intere conferendo loro opzioni speciali e dati di zona Sicurezza BIND supporta vari metodi di protezione per l'aggiornamento e il trasferimento di zone, in entrambi i server master e slave: DNSSEC Abbreviazione di DNS SECurity, questa caratteristica consente di firmare crittograficamente le zone con una chiave di zona. In tal modo le informazioni relative a zone specifiche possono essere verificate come provenienti da un server che le ha firmate con una determinata chiave privata, se il destinatario possiede la chiave pubblica del server dei nomi. La versione 9 di BIND supporta inoltre il metodo SIG(0) chiave pubblica/privata per l'autenticazione del messaggio. TSIG Abbreviazione di Transaction SIGnatures, questa caratteristica permette un trasferimento da master a slave solo dopo aver verificato l'esistenza della chiave segreta condivisa su entrambi i server dei nomi. Questa caratteristica rafforza il metodo IP standard basato sull'indirizzo per l'autorizzazione al trasferimento. Infatti un eventuale intruso per poter trasferire la zona non solo dovrebbe conoscere l'indirizzo IP ma anche la chiave segreta. La versione 9 di BIND supporta inoltre TKEY, ovvero un altro metodo a chiave segreta condivisa per l'autorizzazione a trasferimenti di zona. 59

67 6. Errori comuni da evitare 5.4. IP versione 6 La versione 9 di BIND supporta il servizio del nome in ambienti IP versione 6 (IPv6) utilizzando i record di zona A6. Se il vostro ambiente di rete comprende host con IPv4 e IPv6, è necessario usare il demone lwresd, lightweight resolver daemon, nei vostri client. Questo demone è un server dei nomi 'caching-only' davvero efficiente, che riconosce i nuovi record A6 e DNAME utilizzati con IPv6. Per maggiori informazioni, consultate la pagina man di lwresd. 6. Errori comuni da evitare Spesso i principianti commettono alcuni errori quando modificano i file di configurazione di BIND. Assicuratevi quindi di evitare i seguenti problemi: Quando modificate un file zone, assicuratevi di incrementare il numero seriale. Se non incrementate il numero seriale, il server dei nomi master potrà disporre delle nuove informazioni, ma il server dei nomi slave non riceverà notifiche di cambiamenti, e non aggiornerà quindi i propri dati relativi a quella zona. Ricordatevi di usare in modo corretto le parentesi graffe e i punti e virgola nel file / etc/named.conf Se omettete un punto e virgola oppure una parentesi, ne consegue il rifiuto di named all'avvio. Non dimenticate di mettere i punti (.) nei file zone dopo tutti gli FQDN e di ometterli negli hostname. Il punto indica che il nome assegnato è completo. Se manca il punto, named completerà questo nome con quello della zona o con il valore di $ORIGIN. Se un firewall blocca le connessioni tra il demone named e altri server dei nomi, potrebbe essere necessario modificare il file di configurazione. Per default, la versione 9 di BIND utilizza infatti porte randomiche superiori alla 1024 per interrogare altri nameserver. Alcuni firewall, tuttavia, presuppongono che i nameserver comunichino tra loro utilizzando la porta 53. Quindi per forzare named all'uso della porta 53, inserite la seguente riga nell'istruzione options di /etc/named.conf: query-source address * port 53; 7. Risorse aggiuntive Le seguenti fonti potranno fornirvi ulteriori informazioni relative all'uso di BIND Documentazione installata BIND presenta una documentazione completa su numerosi argomenti, ognuno dei quali contenuto all'interno si una directory. Per ogni simbolo, sostituite <numero-versione> con la versione di bind installata sul sistema: 60

68 7.2. Siti Web utili /usr/share/doc/bind-<version-number>/ Questa directory elenca le caratteristiche più recenti. /usr/share/doc/bind-<version-number>/arm/ Questa directory contiene i formati HTML e SGML del BIND 9 Administrator Reference Manual, il quale elenca i requisiti delle risorse di BIND, illustra come configurare diversi tipi di server dei nomi, come eseguire il bilanciamento del carico e spiega altre caratteristiche avanzate. Questo manuale è il punto di partenza, soprattutto per i nuovi utenti di BIND. /usr/share/doc/bind-<version-number>/draft/ Questa directory contiene diversi documenti tecnici che affrontano problematiche relative al servizio DNS, e relativi metodi per una loro soluzione. /usr/share/doc/bind-<version-number>/misc/ Questa directory contiene i documenti ideati per trattare tematiche complesse. Gli utenti della versione 8 di BIND dovrebbero consultare il documento migration, per le modifiche da eseguire prima di migrare alla versione 9 di BIND. Il file options elenca tutte le opzioni implementate in BIND 9 e utilizzate in /etc/named.conf. /usr/share/doc/bind-<version-number>/rfc/ Questa directory fornisce qualsiasi documento RFC relativo a BIND. Con BIND sono presenti numerose pagine man per varie applicazioni e per i file di configurazione. Il seguente elenco riporta alcune delle pagine man più importanti. Applicazioni di gestione man rndc Esplicita opzioni diverse disponibili usando il comando rndc per controllare un server dei nomi BIND. Applicazioni del server man named Esplicitano diversi argomenti che possono essere usati per controllare il demone del server dei nomi BIND. man lwresd Descrive lo scopo e le opzioni disponibili per il demone lightweight resolver. File di configurazione man named.conf Un elenco completo delle opzioni disponibili all'interno del file di configurazione named. man rndc.conf Un elenco completo delle opzioni disponibili all'interno del file di configurazione rndc Siti Web utili La home page del progetto BIND contenente le in- 61

69 7.3. Libri correlati formazioni relative alle release attuali e della versione PDF del BIND 9 Administrator Reference Manual. Illustra l'uso di BIND come nameserver di risoluzione, 'caching', e la configurazione dei vari file zone che fungono da nameserver primari per un dominio Libri correlati DNS e BIND di Paul Albitz e Cricket Liu; O'Reilly & Associates Un libro di riferimento molto diffuso che illustra le opzioni di configurazione di BIND, incluso le strategie per rendere sicuro un server DNS. The Concise Guide to DNS and BIND di Nicolai Langfeldt; edito da Que approfondisce la connessione tra servizi di rete multipli e BIND, concentrandosi in modo particolare sugli argomenti tecnici "task-oriented". 62

70 Capitolo 4. OpenSSH SSH (o Secure SHell) è un protocollo in grado di facilitare le comunicazioni sicure tra due sistemi utilizzando un'architettura client/server, e permette altresì agli utenti di eseguire un login su sistemi host server in modo remoto. Diversamente da altri protocolli di comunicazione remoti, come ad esempio FTP o Telnet, SSH #cripta la sesione di login rendendo così difficile per gli utenti maliziosi ottenere password non cifrate. SSH è stato ideato per sostituire le applicazioni meno sicure e più obsolete utilizzate per eseguire un login su host remoti, come ad esempio telnet o rsh. Un programma chiamato scp sostituisce programmi più vecchi creati per copiare i file tra host, come rcp. Poichè le applicazioni più obsolete non cifrano le password trasmesse tra client e server, se possibile cercate di non utilizzarle. Utilizzando metodi più sicuri per eseguire un login su sistemi remoti, diminuirete i rischi sia per il sistema client che per l'host remoto. 1. Caratteristiche di SSH Il protocollo SSH fornisce le seguenti funzioni: Dopo un collegamento iniziale, il client è in grado di verificare se il suo collegamento è stato effettuato sullo stesso server sul quale si è precedentemente collegato. Il client trasmette le proprie informazioni di autenticazione al server, utilizzando una cifratura molto sicura a 128-bit. Tutti i dati inviati e ricevuti durante una sessione vengono trasferiti utilizzando una cifratura a 128-bit, rendendo le trasmissioni intercettate estremamente difficili da decifrare e leggere. Il client è in grado di inoltrare applicazioni 1 X11 dal server. Questa tecnica chiamata X11 forwarding, fornisce un metodo sicuro per utilizzare applicazioni grafiche attraverso la rete. Poichè il protocollo SSH cifra qualsiasi cosa inviata o ricevuta, esso può essere utilizzato per rendere sicuri protocolli non sicuri. Usando una tecnica chiamata port forwarding, un server SSH può diventare un condotto per rendere sicuri protocolli non sicuri, come POP, aumentando la sicurezza generale dei dati e del sistema. Il client ed il server OpenSSH possono essere configurati in modo da creare un tunnel simile ad una rete privata virtuale, per il traffico presente tra le macchine client ed il server. Red Hat Enterprise Linux include il pacchetto generale OpenSSH (openssh) insieme al server OpenSSH (openssh-server) ed ai pacchetti (openssh-clients) del client. Nota bene, i pacchetti OpenSSH necessitano del pacchetto OpenSSL (openssl), il quale è in grado d'installare alcune librerie di cifratura molto importanti, permettendo a OpenSSH di fornire comunicazioni cifrate Perchè utilizzare OpenSSH? Utenti maliziosi hanno a disposizione una varietà di tool che permette loro di arrestare, intercettare, e ridirezionare il traffico di rete in modo da ottenere accesso su di un determinato sistema. 1In X11 termini si riferisce generali a X11R7 questi windowing pericoli display vengono system, classificati comunemente nel chiamato modo Sistema seguente: X Window o X. Red Hat Enterprise Linux include X11R7, un sistema X Window della open source. 63

71 2. Versioni del protocollo SSH Intercettazione delle comunicazioni tra due sistemi In questo esempio l'aggressore si può trovare in qualsiasi posizione della rete utilizzata dai soggetti in comunicazione tra loro. Egli è in grado di intercettare e mantenere informazioni, o alterarle ed inviarle all'utente desiderato. Questo attacco può essere portato a termine attraverso l'utilizzo di un packet sniffer una utility di rete molto comune. Fingersi un host particolare Utilizzando questa strategia, il sistema di un aggressore viene configurato in modo da comportarsi come il destinatario inteso della trasmissione. Se questa strategia funziona, il sistema dell'utente non sarà a conoscenza che la comunicazione in corso è con un host malizioso. Questo attacco viene portato a termine attraverso la tecnica conosciuta come DNS poisoning 2 o IP spoofing 3. Entrambi le tecniche sono in grado di intercettare informazioni molto sensibili e, se l'intercettazione viene fatta con intenti ostili, i risultati possono essere critici. È possibile diminuire i suddetti rischi riguardanti la sicurezza, se utilizzate SSH per un login remoto sulla shell e per un processo di copiatura dei file. Questo processo è reso possibile poichè il server ed il client SSH utilizzano firme digitali per verificare l'identità. In aggiunta, tutte le comunicazioni tra i sistemi server e client sono cifrate. I tentativi di ottenere l'identità di una delle parti in comunicazione non verrà portato a termine poichè, ogni pacchetto verrà cifrato utilizzando una chiave conosciuta solo dal sistema locale e remoto. 2. Versioni del protocollo SSH Il protocollo SSH permette a qualsiasi programma server e client, creato per le specifiche del protocollo, di comunicare in modo sicuro e di poter essere usato in modo intercambiabile. Sono presenti attualmente due tipi di SSH (versione 1 e versione 2). La suite OpenSSH con Red Hat Enterprise Linux utilizza la versione 2 di SSH la quale presenta una versione migliorata dell'algoritmo di scambio della chiave, la quale non risulta essere vulnerabile tanto quanto sulla versione 1. Tuttavia la suite OpenSSH supporta i collegamenti della versione 1. Importante Quando possibile è consigliato utilizzare solo client e server compatibili con la versione 2 di SSH. 3. Sequenza eventi di un collegamento SSH I seguenti eventi contribuiscono alla protezione dell'integrità delle comunicazioni SSH tra due 2 il DNS poisoning si verifica quando un aggressore si introduce in un server DNS, direzionando i sistemi client verso un host malizioso. 3 l'ip spoofing si verifica quando un aggressore invia pacchetti di rete i quali appaiono erroneamente provenienti da un host fidato presente sulla rete. 64

72 3.1. Livello di trasporto host. 1. Viene creato un cryptographic handshake in modo tale che il client è in grado di verificare se è in comunicazione con il server corretto. 2. Il livello di trasporto del collegamento tra i client e l'host remoto viene cifrato utilizzando un codice simmetrico. 3. Il client autentica se stesso nei confronti del server. 4. Il client remoto interagisce con l'host remoto attraverso un collegamento cifrato Livello di trasporto Il ruolo primario del livello di trasporto è quello di facilitare una comunicazione affidabile e sicura tra due host, al momento dell'autenticazione e durante le successive comunicazioni. Il livello di trasporto gestisce questo processo tramite la codifica e decodifica dei dati, e fornendo una protezione dell'integrità dei pacchetti dati durante l'invio e la ricezione. Il livello di trasporto fornisce un processo di compressione, velocizzando il trasferimento delle informazioni. Una volta che il client SSH contatta un server, vengono scambiate le informazioni sulla chiave in modo tale che i due sistemi possano creare correttamente un livello di trasporto. Di seguito vengono riportate le seguenti informazioni durante il processo sopra indicato: Vengono scambiate le chiavi Viene determinato l'algoritmo di cifratura della chiave pubblica Viene determinato l'algoritmo di cifratura simmetrico Viene determinato l'algoritmo di autenticazione del messaggio Determinazione dell'algoritmo hash Durante lo scambio della chiave, il server si identifica nei confronti del client con una chave host unica. Se il client non ha mai comunicato prima con il server in questione, la chiave host del server risulta essere sconosciuta al client ed il collegamento viene così rifiutato. OpenSSH aggira questo ostacolo accettando la chiave host del server. Tale accettazione viene eseguita dopo la notifica all'utente, il quale a sua volta ha accettato e verificato la nuova chiave host. Durante i collegamenti successivi, la chiave host del server viene controllata con la versione precedentemente salvata presente sul client, assicurando così che il client è in comunicazione con il server desiderato. Se in futuro la chiave host non corrisponde più a quella precedentemente conservata, l'utente dovrà rimuovere la versione salvata del client prima di potersi collegare. Attenzione È possibile per un aggressore comportarsi come un server SSH durante il contatto iniziale, poichè il sistema locale non riesce a riconoscere il server desiderato da quello impostato dall'aggressore. Per prevenire ciò verificate l'integrità di un nuovo 65

73 3.2. Autenticazione server SSH, contattando semplicemente l'amministratore del server prima di collegarvi per la prima volta, oppure in presenza di una discordanza tra le chiavi host. SSH è stato ideato per funzionare con quasi tutti gli algoritmi della chiave pubblica o del formato di cifratura. Dopo che una scambio di chiavi iniziale crea un valore hash utilizzato per gli scambi e per il valore segreto condiviso, i due sistemi iniziano subito il calcolo delle nuove chiavi e degli algoritmi, per proteggere il processo di autenticazione insieme ai dati futuri inviati attraverso il collegamento. Dopo aver trasmesso una certa quantità di dati utilizzando una determinata chiave ed un algoritmo (la quantità esatta dipende dall'implementazione SSH), si verificherà un'altro scambio di chiavi, generando così un altro set di chiavi di valore hash insieme ad un valore segreto condiviso. Anche se un aggressore è in grado di determinare il valore segreto condiviso e quello hash, essi possono essere utilizzati solo per un periodo di tempo limitato Autenticazione Una volta stabilito un tunnel sicuro da parte del livello di trasporto, attraverso il quale è possibile passare informazioni tra due sistemi, il server informa il client sui diversi metodi di autenticazione supportati, come ad esempio la firma chiave-codificata privata oppure l'inserimento di una password. Successivamente il client tenta di autenticare se stesso nei confronti del server utilizzando uno dei suddetti metodi. I client ed i server SSH possono essere configurati in modo da permettere diversi tipi di autenticazione, conferendo così ad entrambe le parti un controllo molto efficace. Il server è in grado di decidere i metodi di cifratura supportati in base al proprio modello di sicurezza, ed il client è in grado di scegliere l'ordine dei metodi di autenticazione dalle opzioni disponibili Canali Dopo un processo di autenticazione corretto attraverso il livello di trasporto SSH, verranno aperti canali multipli tramite una tecnica chiamata multiplexing 4. Ogni canale gestisce le comunicazioni per sessioni diverse del terminale e per sessioni X11 inoltrate. Sia i client che i server sono in grado di creare un nuovo canale. Ad ogni canale verrà assegnato un numero diverso ad ogni estremità del collegamento. Quando il client cerca di aprire un nuovo canale, i client inviano il numero del canale insieme alla richiesta. Queste informazioni verranno conservate dal server ed utilizzate per inviare la comunicazione al canale in questione. Il tutto viene portato a termine in modo tale che le diverse sessioni non entrano in conflitto tra loro, così al termine della sessione stessa, il canale relativo può essere chiuso senza disturbare il collegamento SSH primario. I canali supportano anche il flow-control, il quale permette loro di inviare e ricevere dati seguendo un certo ordine. In questo modo, i dati non verranno inviati attraverso il canale fino a quando il client riceve un messaggio indicando l'apertura del canale. 4 Un collegamento di tipo 'multiplexed' consiste in un numero considerevole di segnali inviati attraverso un mezzo comune condiviso. Con SSH verranno inviati attraverso un collegamento sicuro comune, un certo numero di canali. 66

74 4. Configurazione di un server OpenSSH Il client ed il server negozieranno automaticamente tra loro le caratteristiche di ogni canale, tale processo verrà eseguito considerando il tipo di servizio richiesto dal client, ed il modo in cui l'utete risulta collegato alla rete. Il tutto garantisce una certa flessibilità nella gestione di diversi tipi di collegamenti remoti, senza modificare l'infrastruttura di base del protocollo. 4. Configurazione di un server OpenSSH Prima di eseguire un server OpenSSH è necessario verificare che siano installati i pacchetti RPM appropriati. Il pacchetto openssh-server risulta essere necessario e dipende dal pacchetto openssh. Il demone OpenSSH utilizza il file di configurazione /etc/ssh/sshd_config. Il file di configurazione di default dovrebbe essere sufficiente per gran parte degli usi. Se volete configurare il demone in modo diverso dalla configurazione di default di fornita dasshd_config, consultate la pagina man del comando sshd per ottenere un elenco delle parole chiave che possono essere incluse nel file di configurazione. Se eseguite una nuova installazione, il sistema reinstallato crea un nuovo set di chiavi per l'identificazione. Qualsiasi client collegato al sistema con qualsiasi tool OpenSSH, prima della reinstallazione visualizzeranno i WARNING: REMOTE HOST IDENTIFICATION IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. Se desiderate conservare le chiavi host generate per il sistema, eseguite un backup dei file / etc/ssh/ssh_host*key* e ripristinateli dopo il processo di reinstallazione. Questo processo conserva l'identità del sistema e quando i client tenteranno di collegarsi a; sistema dopo la reinstallazione, non riceveranno il messaggio di avviso SSH necessario per collegamenti remoti Per sfruttare al massimo le potenzialità di SSH, è sconsigliato l'utilizzo di protocolli non sicuri come Telnet e FTP. In caso contrario, la password di un utente può essere protetta per una sessione utilizzando SSH, ma essere catturata più in avanti eseguendo un login durante l'utilizzo di Telnet. Alcuni servizi da disabilitare includono: telnet rsh rlogin vsftpd Per disabilitare i metodi di collegamento non sicuri al sistema, utilizzate il programma della linea di comando chkconfig, il programma basato su ncurses /usr/sbin/ntsysv, o l'applicazione grafi- 67

75 5. File di configurazione di OpenSSH ca Tool di configurazione dei servizi (system-config-services). Tutti questi tool richiedono un livello d'acceso root. 5. File di configurazione di OpenSSH OpenSSH possiede due set diversi di file di configurazione: uno per i programmi client (ssh, scp, e sftp), ed uno per il demone del server (sshd). Le informazioni sulla configurazione di SSH dell'intero sistema vengono conservate all'interno della directory /etc/ssh/: moduli Contiene i gruppi Diffie-Hellman utilizzati per lo scambio della chiave Diffie- Hellman, critica per la creazione di un livello di trasporto sicuro. Al momento di uno scambio di chiavi all'inizio di una sessione SSH, verrà creato un valore segreto condiviso il quale non potrà essere determinato da una sola entità. Il suddetto valore viene utilizzato per fornire un'autenticazione host. ssh_config Il file di configurazione del client SSH di default del sistema. Verrà sovrascritto se è presente un altro file di configurazione all'interno della home directory dell'utente (~/.ssh/config). sshd_config Il file di configurazione per il demone sshd. ssh_host_dsa_key La chiave privata DSA utilizzata dal demone sshd. ssh_host_dsa_key.pub La chiave pubblica DSA utilizzata dal demone sshd. ssh_host_key La chiave privata RSA utilizzata dal demone sshd per la versione 1 del protocollo SSH. ssh_host_key.pub La chiave pubblica RSA utilizzata dal demone sshd per la versione 1 del protocollo SSH. ssh_host_rsa_key La chiave privata RSA utilizzata dal demone sshd per la versione 2 del protocollo SSH. ssh_host_rsa_key.pub La chiave pubblica RSA utilizzata da sshd per la versione 2 del protocollo SSH. Le informazioni sulla configurazione SSH specifiche per l'utente, vengono conservate nella directory home dell'utente stesso all'interno della directory ~/.ssh/: authorized_keys Questo file contiene un elenco delle chiavi pubbliche autorizzate per i server. Quando il client si collega ad un server, il server stesso autentica il client eseguendo un controllo della sua chiave pubblica conservata all'interno di questo file. id_dsa Contiene la chiave privata DSA dell'utente. id_dsa.pub La chiave pubblica DSA dell'utente. id_rsa La chiave privata RSA utilizzata da ssh per la versione 2 del protocollo SSH. id_rsa.pub La chaive pubblica RSA utilizzata da ssh per la versione 2 del protocollo SSH. 68

76 6. Configurazione del client OpenSSH identity La chiave privata RSA utilizzata da ssh per la versione 1 del protocollo SSH. identity.pub La chiave pubblica RSA utilizzata da ssh per la versione 1 del protocollo SSH. known_hosts Questo file contiene le chiavi host DSA dei server SSH accessi dall'utente. Esso risulta essere molto importante per assicurare il collegamento del client SSH al corretto server SSH. Importante Se è stata modificata la chiave host del server SSH, il client notificherà all'utente l'impossibilità di effettuare alcun collegamento, fino a quando la chiave host del server non verrà cancellata dal file known_hosts utilizzando un editor di testo. Prima di fare ciò, tuttavia, contattate l'amministratore del sistema del server SSH, in modo da verificare che il server non sia compromesso. Consultate le pagine man ssh_config e sshd_config per informazioni sulle diverse direttive disponibili all'interno dei file di configurazione SSH. 6. Configurazione del client OpenSSH Per collegarvi a un server OpenSSH tramite un computer client, è necessario che siano installati i pacchetti openssh-clients e openssh Uso del comando ssh Il comando ssh può essere considerato una valida alternativa ai comandi rlogin, rsh e telnet. Questo comando permette di collegarsi e di eseguire comandi su una macchina remota. L'uso del comando ssh per collegarsi a un computer remoto è simile al comando telnet. Per collegarvi a un computer remoto penguin.example.net, digitate il comando seguente al prompt della shell: ssh penguin.example.net La prima volta che vi collegate a una macchina remota tramite il comando ssh, compare un messaggio simile al seguente: L'autenticità dell'host penguin.example.net' non può essere stabilita. L'impronta digitale della chiave DSA è 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c. Siete sicuri di voler continuare il collegamento (si/no)? Digitate si per continuare. In questo modo aggiungete il server all'elenco degli host conosciuti (~/.ssh/known_hosts/) come visualizzato nel seguente messaggio: Avvertimento: Aggiunto in modo permanente 'penguin.example.net' (RSA) all'elenco di host conosciuti. Successivamente compare il prompt per l'inserimento della password di accesso al server re- 69

77 6.2. Uso del comando scp moto. Una volta inserita la password, compare il prompt della shell. Se non specificate un nome utente, viene passato alla macchina remota il nome utente usato per l'accesso alla macchina client locale. Per specificare un nome utente differente, usate il seguente comando: ssh Potete anche usare la sintassi ssh -1 nomeutente penguin.example.net. Il comando ssh può essere utilizzato per eseguire direttamente un comando su una macchina remota senza collegarsi al prompt della shell. La sintassi è ssh nomehostcomando. Per esempio, se volete eseguire il comando ls /usr/share/doc sulla macchina remota penguin.example.net, digitate il seguente comando al prompt della shell: ssh penguin.example.net ls /usr/share/doc Dopo aver inserito la password corretta, viene visualizzato il contenuto della directory / usr/share/doc. Quindi ritornerete al prompt della shell Uso del comando scp Il comando scp viene usato per trasferire file tra computer tramite una connessione sicura e criptata. E` simile al comando rcp. La sintassi generale per trasferire file locali su un sistema remoto è la seguente: scp <localfile>username@tohostname:<remotefile> <localfile> specifica la fonte insieme con il percorso del file, come ad esempio / var/log/maillog. <remotefile> specifica la destinazione, la quale può essere un nuovo filename come ad esempio /tmp/hostnam log. Per un sistema remoto, se / non precede il resto del percorso, il suddetto percorso sarà relativo alla home directory di username, generalmente / home/username/. Per trasferire il file locale shadowman su di una home directory del vostro account su penguin.example.net, digitate il comando seguente al prompt della shell (sostituendo username con il vostro nome utente): scp shadowman username@penguin.example.net:shadowman Questo comando trasferisce il file locale shadowman su /home/username/shadowman su penguin.example.net. Alternativamente, potete estromettere l'ultimo shadowman nel comando scp. La sintassi per trasferire un file da una macchina remota al sistema locale è la seguente: scp username@tohostname:<remotefile><newlocalfile> <remotefile> specifica la sorgente incluso il percorso, e <newlocalfile> specifica la destinazione incluso il percorso. File multipli possono essere specificati come file sorgente. Per esempio per trasferire il contenuto della directory /downloads su di una directory esistente chiamata uploads presente sulla macchina remota penguin.example.net, digitate al prompt della shell il comando seguente: 70

78 6.3. Utilizzo del comando sftp scp downloads/* 6.3. Utilizzo del comando sftp L'utility sftp è utilizzata per sessioni FTP interattive e sicure. È simile al comando ftp tranne per il fatto che utilizza una connessione sicura e criptata. La sintassi è sftp nomeutente@nomehost.com. Completata la fase di autenticazione, potete utilizzare il set di comandi simile all'ftp. Consultate la pagina man del comando sftp per ottenere un elenco di questi comandi. Per leggere la pagina man, eseguite il comando man sftp al prompt della shell. L'utility sftp è disponibile a partire dalla versione 2.5.0p1 e successiva di OpenSSH. 7. Più di una semplice Secure Shell Una interfaccia della linea di comando sicura rappresenta solo l'inizio dei diversi modi di utilizzo di SSH. Data una corretta ampiezza di banda, le sessioni X11 possono essere dirottate attraverso un canale SSH. Oppure utilizzando TCP/IP forwarding, i collegamenti precedentemente considerati non sicuri tra sistemi possono essere mappati su canali SSH specifici X11 Forwarding Aprire una sessione X11 attraverso un collegamento SSH, è semplice tanto quanto collegarsi al server SSH utilizzando l'opzione -Y ed eseguire un programma X su di una macchina locale. ssh -Y <user>@example.com Quando un programma X viene eseguito da un prompt della secure shell, il client SSH ed il server creano un nuovo canale sicuro, ed i dati del programma X vengono inviati, attraverso quel canale, alla macchina del client in modo trasparente. X11 forwarding può essere molto utile, esso infatti può essere usato per creare una sessione interattiva e sicura di Tool di configurazione della stampante. Per fare ciò collegatevi al server utilizzando ssh e successivamente digitate: system-config-printer & Dopo aver fornito la password root per il server, verrà visualizzato Tool di configurazione della stampante, il quale permetterà all'utente remoto di configurare in modo sicuro il processo di stampa su di un sistema remoto Port Forwarding SSH è in grado di rendere sicuro protocolli TCP/IP insicuri tramite il port forwarding. Quando viene utilizzata questa tecnica il server SSH diviene un condotto cifrato per il client SSH. Port forwarding mappa una porta locale presente sul client su di una porta remota del server. SSH può mappare qualsiasi porta del server su qualsiasi porta presente sul client; questa tecnica funziona anche se i numeri della porta non corrispondono. Per creare un canale per il TCP/IP Port forwarding in ascolto per collegamenti sull'host locale, utilizzate il seguente comando: 71

79 7.3. Come generare le coppie di chiavi ssh -L Nota Bene Per impostare il port forwarding in ascolto su porte minori di 1024, avrete bisogno di un livello di accesso root. Per controllare le sul server chiamato mail.example.com utilizzando POP3 attraverso un collegamento cifrato, utilizzate il seguente comando: ssh -L 1100:mail.example.com:110 mail.example.com Una volta presente un canale per il port forwarding tra la macchina client ed il mail server, direzionate un POP3 mail server in modo da utilizzare la porta 1100 sull'host locale, in modo da controllare la presenza di nuova posta. Qualsiasi richiesta inviata alla porta 1100 sul sistema client, verrà direzionata in modo sicuro al server mail.example.com. Se mail.example.com non esegue il server SSH, ma un'altra macchina presente sulla stessa rete stà eseguendo questo processo, SSH può essere ancora utilizzato per rendere sicuro parte del collegamento. Tuttavia sarà necessario emettere un comando leggermente diverso: ssh -L 1100:mail.example.com:110 other.example.com In questo esempio le richieste POP3 provenienti dalla porta 1100 sulla macchina client, vengono inoltrate attraverso il collegamento SSH sulla porta 22 sul server SSH, other.example.com. Successivamente, other.example.com si collega alla porta 110 su mail.example.com per controllare la presenza di nuova posta. Quando utilizzate questa tecnica, ricordate che solo il collegamento tra il sistema client ed il server SSH other.example.com risulta essere sicuro. Il Port forwarding può essere utilizzato per ottenere le informazioni in modo sicuro attraverso i firewall di rete. Se il firewall è stato configurato per permettere la presenza di traffico SSH attraverso la propria porta standard (22), bloccando qualsiasi accesso ad altre porte, un sarà ancora possibile eseguire un collegamento tra due host utilizzando le porte bloccate, ridirezionando semplicemente la propria comunicazione attraverso un collegamento SSH già esistente. Nota Bene Utilizzando il port forwarding per inoltrare i collegamenti in questo modo, permetterà qualsiasi utente presente sul sistema client di collegarsi al servizio in questione. Se il sistema client risulta essere compromesso, l'aggressore avrà accesso ai servizi inoltrati. Gli amministratori che non desiderano implementare il port forwarding possono disabilitare questa funzione sul server, specificando un parametro No per la riga AllowTcpForwarding in /etc/ssh/sshd_config, e successivamente riavviare il servizio sshd. 72

80 7.3. Come generare le coppie di chiavi 7.3. Come generare le coppie di chiavi Se non volete inserire la vostra password ogni volta che usate i comandi ssh, scp o sftp per collegarvi a una macchina remota, potete generare una coppia di chiavi di autorizzazione. Le chiavi devono essere generate per ogni utente. Per generare le chiavi per un utente, eseguite la procedura seguente collegandovi con il vostro nome utente. Se vi collegate come root, solo l'utente root potrà utilizzare le chiavi. Se eseguite l'avvio con la versione 3.0 di OpenSSH, ~/.ssh/authorized_keys2, ~/.ssh/known_hosts2 e /etc/ssh_known_hosts2 risultano obsoleti. I protocolli 1 e 2 di SSH condividono i file ~/.ssh/authorized_keys, ~/.ssh/known_hosts e /etc/ssh/ssh_known_hosts. Red Hat Enterprise Linux utilizza le chiavi SSH Protocol 2 e RSA per default. Suggerimento Se effettuate una reinstallazione ma desiderate salvare la coppia di chiavi generata, eseguite il backup della directory.ssh nella vostra directory home. Dopo la reinstallazione copiate questa directory nella vostradirectory home. Questo processo può essere eseguito per tutti gli utenti del sistema, inclusi gli utenti root Come generare una coppia di chiavi RSA per la versione 2 Per generare una coppia di chiavi RSA per la versione 2 del protocollo SSH, utilizzate la seguente procedura, che rappresenta il punto di partenza di default relativo a OpenSSH Per generare una coppia di chiavi RSA da utilizzare con la versione 2 del protocollo, digitate il seguente comando al prompt della shell: ssh-keygen -t rsa Accettate il percorso predefinito del file ~/.ssh/id_rsa. Immettete una frase di accesso diversa dalla password del vostro account e confermatela digitandola una seconda volta. La chiave pubblica verrà scritta in ~/.ssh/id_rsa.pub, mentre la chiave privata verrà scritta in ~/.ssh/id_rsa. Non comunicate mai la vostra chiave privata a nessuno. 2. Modificate i permessi per la directory.ssh usando il seguente comando: chmod 755 ~/.ssh 3. Copiate i contenuti di ~/.ssh/id_rsa.pub in ~/.ssh/authorized_keys sulla macchina alla quale desiderate collegarvi. Se il file ~/.ssh/authorized_keys esiste, potete copiare i contenuti del file ~/.ssh/id_rsa.pub nel file ~/.ssh/authorized_keys sull'altra macchina. 4. Modificate i permessi del file authorized_keysusando il seguente comando: chmod 644 ~/.ssh/authorized_keys 73

81 7.3. Come generare le coppie di chiavi 5. Se state eseguendo GNOME o un desktop grafico con librerie GTK2+, andate su Sezione 7.3.4, Configurazione di ssh-agent con una GUI. Se non state eseguendo il sistema X Window, andate su Sezione 7.3.5, Configurazione di ssh-agent Come generare una coppia di chiavi DSA per la versione 2 Per generare una coppia di chiavi DSA per la versione 2 del protocollo SSH, eseguite la procedura qui descritta. 1. Per generare una coppia di chiavi DSA per la versione 2 del protocollo, digitate il seguente comando al prompt della shell: ssh-keygen -t dsa Accettate il percorso predefinito del file ~/.ssh/id_dsa. Immettete una frase di accesso diversa dalla password del vostro account e confermatela inserendola una seconda volta. Suggerimento Una frase di accesso è una sequenza di parole e caratteri utilizzata per autenticare l'utente. Al contrario delle password, le frasi di accesso possono contenere anche spazi e tabulazioni. Inoltre le frasi di accesso sono generalmente più lunghe delle password poiché possono contenere più parole. La chiave pubblica verrà scritta in ~/.ssh/id_dsa.pub, mentre la chiave privata verrà scritta in ~/.ssh/id_dsa. Non comunicate mai la vostra chiave privata a nessuno. 2. Modificate i permessi della directory.ssh mediante il seguentecomando: chmod 755 ~/.ssh 3. Copiate i contenuti di ~/.ssh/id_dsa.pub in ~/.ssh/authorized_keys sulla macchina alla quale volete collegarvi. Se il file ~/.ssh/authorized_keysesiste, potete copiare i contenuti del file ~/.ssh/id_dsa.pub nel file ~/.ssh/authorized_keys sull'altra macchina. 4. Modificate i permessi del file authorized_keysusando il seguente comando: chmod 644 ~/.ssh/authorized_keys 5. Se state eseguendo GNOME o un desktop grafico con librerie GTK2+, andate su Sezione 7.3.4, Configurazione di ssh-agent con una GUI. Se non state eseguendo il sistema X Window, andate su Sezione 7.3.5, Configurazione di ssh-agent Come generare una coppia di chiavi RSA per le versioni 1.3 e 1.5 Eseguite la procedura seguente per generare una coppia di chiavi RSA per la versione 1 del protocollo SSH. Se effettuate solo connessioni tra sistemi Red Hat Linux, non dovete generare 74

82 7.3. Come generare le coppie di chiavi una coppia di chiavi RSA versione 1.3 o RSA versione Per generare une coppia di chiavi RSA (per le versioni 1.3 e 1.5), digitate il comando seguente al prompt della shell: ssh-keygen -t rsa1 Accettate il percorso predefinito del file (~/.ssh/identity). Immettete una frase di accesso diversa dalla vostra password di account e confermatela digitandola una seconda volta. La chiave pubblica verrà scritta in ~/.ssh/identity.pub, mentre la chiave privata verrà scritta in ~/.ssh/identity. Non comunicate mai la vostra chiave privata a nessuno. 2. Modificate i permessi della directory.ssh e le vostre chiavi tramite i comandi chmod 755 ~/.ssh e chmod 644 ~/.ssh/identity.pub. 3. Copiate il contenuto di ~/.ssh/identity.pub nel file ~/.ssh/authorized_keys della macchina remota alla quale volete collegarvi. Se il file ~/.ssh/authorized_keys non esiste, potete copiare il file ~/.ssh/identity.pub nel file ~/.ssh/authorized_keys sulla macchina remota. 4. Se state eseguendo GNOME, andate su Sezione 7.3.4, Configurazione di ssh-agent con una GUI. Se non state eseguendo GNOME, andate su Sezione 7.3.5, Configurazione di ssh-agent Configurazione di ssh-agent con una GUI L'utility ssh-agent può essere usata per salvare la frase di accesso ed evitare di ridigitarla ogni volta che attivate una connessione ssh o scp. Se utilizzate GNOME il pacchetto gnomessh-askpass contiene l'applicazione usata per richiedere la frase di accesso al momento della connessione a GNOME e per conservarla fino alla disconnessione. Non sarà necessario inserire la vostra password o frase di accesso per le connessioni ssh o scp effettuate durante la sessione di GNOME. Se non state usando GNOME, consultate Sezione 7.3.5, Configurazione di ssh-agent. Per salvare la frase di accesso durante la sessione GNOME, eseguite questa procedura: 1. Avrete bisogno di avere il pacchetto gnome-ssh-askpass; per sapere se tale pacchetto è installato, digitate il comando rpm -q openssh-askpass. Il pacchetto può essere installato dal vostro CD-ROM Red Hat Enterprise Linux, da un sito mirror Red Hat FTP o usando Red Hat Network. 2. Selezionate il Pulsante del menu principale = > (sul Pannello) =>Preferenze => Piú preferenze => Sessioni = > e fate clic sulla scheda Programmi d'avvio. Fate clic su Aggiungi e digitate /usr/bin/ssh-add nell'area Comando d'avvio. Attribuitegli un livello di priorità superiore a qualsiasi altro comando in modo che venga eseguito per ultimo. Vi consigliamo di attribuire a ssh-add un numero uguale o superiore a 70. Più alto è il numero, più bassa è la priorità. Se avete altri programmi in elenco, questo deve avere la priorità più bassa. Selezionate Chiudi per uscire dal programma. 3. Scollegatevi e ricollegatevi a GNOME; in altre parole, riavviate X. Una volta avviato GNO- ME, si apre una finestra di dialogo che richiede l'inserimento della frase di accesso. Inserite 75

83 8. Risorse aggiuntive la frase di accesso richiesta. Se sono state configurate sia le chiavi DSA che RSA, il sistema richiede entrambe le coppie. D'ora in poi, i comandi ssh, scp o sftp non richiedono alcuna password Configurazione di ssh-agent Il comando ssh-agent permette di registrare la frase di accesso per non doverla digitare ogni qualvolta si stabilisce una connessione ssh o scp. Se non usate il sistema X Window, eseguite la procedura di seguito riportata dal prompt della shell. Se siete in GNOME, ma non volete configurarlo in modo che vi chieda la vostra frase di accesso al momento del login (consultate Sezione 7.3.4, Configurazione di ssh-agent con una GUI ), la procedura funziona in un terminal window, come XTerm. Se state eseguendo X, ma non GNOME, la procedura funziona in un terminal window. Tuttavia, la vostra frase di accesso viene memorizzata solo per quel terminal window, non si tratta di un'impostazione valida a livello globale. 1. Al prompt della shell digitate il comando: exec /usr/bin/ssh-agent $SHELL 2. Quindi digitate il comando: ssh-add e inserite la vostra frase di accesso. Se sono configurate più coppie di chiavi, vi vengono richieste tutte le coppie. 3. Quando vi scollegate, la vostra frase di accesso viene cancellata. Ogni volta che vi collegate a una console virtuale o aprite una finestra di terminale, dovete eseguire questi due comandi. 8. Risorse aggiuntive I progetti OpenSSH e OpenSSL sono in continuo sviluppo. Per informazioni più aggiornate, vi consigliamo di collegarvi direttamente al sito Web relativo. Anche le pagine man dei tool OpenSSH e OpenSSL contengono informazioni dettagliate Documentazione installata Pagine man dei comandi ssh, scp, sftp, sshd e ssh-keygen riportano informazioni sull'utilizzo di tali comandi e tutti i parametri a essi associati Siti Web utili [ Il sito contiene la pagina delle FAQ di OpenSSH, i bug report, le mailing list, gli obiettivi del progetto e una spiegazione piùtecnica dei contenuti sulla sicurezza. [ Il sito contiene la pagina delle FAQ di OpenSSL, le mailing list e una descrizione degli obiettivi del progetto. 76

84 8.2. Siti Web utili [ Il software client SSH per altre piattaforme. 77

85 Capitolo 5. Dynamic Host Configuration Protocol (DHCP) Il Dynamic Host Configuration Protocol (DHCP) è un protocollo di rete per l'assegnazione automatica di informazioni TCP/IP alle macchine client. Ciascun client DHCP si collega al server DHCP posizionato centralmente, il quale ritorna la configurazione di rete del client (incluso l'indirizzo IP, ed i server DNS). 1. Perché usare il DHCP? Il DHCP è utile per la configurazione automatica delle interfacce di rete del client. Durante la configurazione del sistema client, l'amministratore può scegliere il DHCP invece di inserire un indirizzo IP, maschera di rete, gateway o server DNS. Il client riprende questa informazione dal server DHCP. Il DHCP si rivela utile anche quando l'amministratore desidera cambiare gli indirizzi IP di un ampio numero di sistemi. Invece di riconfigurare tutti i sistemi, l'amministratore può modificare un solo file di configurazione DHCP sul server per il nuovo set di indirizzi IP. Se i server DNS di un'organizzazione cambiano, le modifiche vengono applicate al server DHCP, non ai client DHCP. Quando un amministratore riavvia la rete o i client, le modifiche saranno effettive. Se una organizzazione possiede un server DHCP funzionale e propriamente collegato ad una rete, gli utenti di laptop ed altri computer portatili possono spostare questi dispositivi da un ufficio ad un altro. 2. Configurazione di un server DHCP Per poter configurare un server DHCP, è necessario creare il file di configurazione dhcpd.conf. Un esempio di file è disponibile su /usr/share/doc/dhcp-<version>/dhcpd.conf.sample. Il DHCP utilizza anche il file /var/lib/dhcpd/dhcpd.leases per archiviare il database in 'affitto' (lease) del client. Per ulteriori informazioni, fate riferimento alsezione 2.2, Database degli affitti File di configurazione La prima fase della configurazione di un server DHCP, è la creazione del file di configurazione contenente le informazioni di rete per i client. Utilizzate questo file per inserire le opzioni e le opzioni globali per i sistemi client. Il file di configurazione può contenere schede e linee vuote aggiuntive per facilitare la formattazione. Le parole chiave distinguono tra lettere maiuscole e lettere minuscole, e le linee che iniziano con cancelletto (#) sono considerate commenti. Due sono gli schemi di aggiornamento DNS attualmente implementati la modalità di aggiornamento DNS ad-hoc e quella della modalità di aggiornamento della bozza di interazione DH- CP-DNS interim. Se e quando queste due modalità vengono accettate come parte del processo degli standard Internet Engineering Task Force (IETF), sarà disponibile una terza modalità il 78

86 2.1. File di configurazione metodo di aggiornamento DNS standard. Il server DHCP deve essere configurato per l'utilizzo di uno dei due schemi correnti. La versione 3.0b2pl11 e le versioni precedenti utilizzavano la modalità ad-hoc, tuttavia questo non è più consigliato. Se desiderate che venga mantenuto lo stesso comportamento, aggiungete la riga riportata di seguito nella parte superiore del file di configurazione: ddns-update-style ad-hoc; Per utilizzare la modalità consigliata, aggiungete la riga riportata di seguito nella parte superiore del file di configurazione: ddns-update-style interim; Per ulteriori informazioni sulle diverse modalità, consultate la pagina man dhcpd.conf. Esistono due tipi di dichiarazioni nei file di configurazione: Parametri Indicano come eseguire un'operazione, se eseguire un'operazione oppure quali opzioni di configurazione di rete inviare al client. Dichiarazioni Descrivono la topologia della rete, i client, forniscono indirizzi per i client o applicano un gruppo di parametri a un gruppo di dichiarazioni. Alcuni parametri che iniziano con la parola chiave opzione vengono indicati come options. Queste opzioni controllano le opzioni DHCP; mentre i parametri configurano i valori non facoltativi oppure controllano l'attività del server DHCP. I parametri (incluse le opzioni) dichiarati prima di una sezione inclusa tra parentesi graffe ({ }) sono considerati parametri globali, ovvero si applicano a tutte le sezioni che li seguono. Importante Se modificate il file di configurazione, le modifiche saranno confermate solo al riavvio del demone DHCP con il comando service dhcpd restart. Suggerimento Invece di modificare un file di configurazione DHCP e riavviare il servizio ogni volta, utilizzando il comando omshell avrete a disposizione una modalità interattiva per interrogare, e modificare la configurazione di un server DHCP. Utilizzando omshell, è possibile eseguire tutte le modifiche mentre il server è in esecuzione. Per maggiori informazioni su omshell, consultate la pagina man di omshell. Nell'Esempio 5.1, Dichiarazione di sottorete le opzioni routers, subnet-mask, domain-name, domain-name-servers, e time-offset, sono utilizzate per le istruzioni host presenti. 79

87 2.1. File di configurazione In aggiunta, è possibile dichiarare una subnet, una dichiarazione subnet deve essere inclusa per ogni sottorete della rete. In caso contrario, il server DHCP non riuscirà ad avviarsi. Quest'esempio riporta delle opzioni globali per ogni client DHCP nella sottorete e un range dichiarato. Ai client viene assegnato un indirizzo IP compreso nel range. subnet netmask { option routers ; option subnet-mask ; option domain-name "example.com"; option domain-name-servers ; option time-offset ; # Eastern Standard Time } range ; Esempio 5.1. Dichiarazione di sottorete Tutte le sottoreti che condividono la stessa rete fisica dovrebbero essere inserite in una dichiarazione shared-network, come mostra l'esempio 5.2, Dichiarazione di rete condivisa. I parametri contenuti nella shared-network, e non nelle dichiarazioni subnet, sono considerati parametri globali. Il nome della shared-network deve essere un titolo descrittivo per la rete, come per esempio 'test-lab' per descrivere tutte le sottoreti in un ambiente di laboratorio di prova. shared-network name { option domain-name "test.redhat.com"; option domain-name-servers ns1.redhat.com, ns2.redhat.com; option routers ; more parameters for EXAMPLE shared-network subnet netmask { parameters for subnet range ; } subnet netmask { parameters for subnet range ; } } Esempio 5.2. Dichiarazione di rete condivisa Come mostrato nell'esempio 5.3, Dichiarazione di gruppo, la dichiarazione group può essere utilizzata per applicare i parametri globali ad un gruppo di dichiarazioni. Per esempio, è possibile raggruppare reti condivise, sottoreti, pure host. group { option routers ; option subnet-mask ; option domain-name "example.com"; option domain-name-servers ; 80

88 2.1. File di configurazione option time-offset ; # Eastern Standard Time host apex { option host-name "apex.example.com"; hardware ethernet 00:A0:78:8E:9E:AA; fixed-address ; } } host raleigh { option host-name "raleigh.example.com"; hardware ethernet 00:A1:DD:74:C3:F2; fixed-address ; } Esempio 5.3. Dichiarazione di gruppo Per configurare un server DHCP che affitta indirizzi IP dinamici al sistema inserito in una sottorete, modificate l'esempio 5.4, Parametro del range inserendo i vostri valori. Tale procedura indica un tempo di affitto di default, il tempo massimo ed i valori della configurazione di rete per i client. L'esempio riportato qui di seguito assegna gli indirizzi IP ai sistemi client nel range e default-lease-time 600; max-lease-time 7200; option subnet-mask ; option broadcast-address ; option routers ; option domain-name-servers , ; option domain-name "example.com"; subnet netmask { range ; } Esempio 5.4. Parametro del range Per assegnare un indirizzo IP a un client che si basa sull'indirizzo MAC di una scheda dell'interfaccia di rete, utilizzare il parametro hardware ethernet contenuto nella dichiarazione host. Come dimostra l'esempio 5.5, Indirizzo IP statico con DHCP, la dichiarazione host apex specifica che la scheda di rete con l'indirizzo MAC 00:A0:78:8E:9E:AA dovrebbe sempre corrispondere all'indirizzo IP Notate che il parametro facoltativo host-name può essere usato per assegnare un host name al client. host apex { option host-name "apex.example.com"; hardware ethernet 00:A0:78:8E:9E:AA; fixed-address ; } Esempio 5.5. Indirizzo IP statico con DHCP 81

89 2.2. Database degli affitti Suggerimento L'esempio fornito del file di configurazione, può essere usato come punto di partenza a cui aggiungere le opzioni di configurazione personalizzata. Per copiarlo nella posizione corretta, usate il seguente comando: cp /usr/share/doc/dhcp-<version-number>/dhcpd.conf.sample /etc/dhcpd.conf (dove <version-number> è la versione del DHCP). Per un elenco completo di dichiarazioni per le opzioni e delle loro funzioni, fate riferimento alla pagina man dhcp-options Database degli affitti Sul server DHCP, il file /var/lib/dhcpd/dhcpd.leases archivia il database degli affitti del client DHCP. Si consiglia di non modificare il file. Le informazioni sull'affitto DHCP per ogni indirizzo IP assegnato di recente sono archiviate automaticamente nel database degli affitti. Le informazioni includono la durata dell'affitto, a chi è stato assegnato l'indirizzo IP, l'inizio e la fine delle date di affitto e l'indirizzo MAC della scheda di interfaccia di rete usata per riprendere l'affitto. Tutti gli orari del database degli affitti fanno riferimento al Coordinated Universal Time (UTC), non all'ora locale. Il database degli affitti viene ricreato qualvolta si desidera limitare la sua dimensione. Come prima cosa tutti gli affitti esistenti vengono salvati in un database temporaneo degli affitti. Il file dhcpd.leases viene rinominato dhcpd.leases~, ed il database temporaneo degli affitti viene salvato nel file dhcpd.leases. Il demone DHCP può essere terminato, o il sistema può essere interrotto, dopo aver rinominato il database in affitto sul file di backup, ma prima di aver salvato il nuovo file. Se ciò accade, il file dhcpd.leasesnon esiste, ma sarà comunque necessario per avviare il servizio. Non create un nuovo file di affitto, in caso contrario tutti gli affitti verranno persi. La soluzione corretta sarà quella di rinominare il file di backup dhcpd.leases~ in dhcpd.leases e quindi avviare il demone Avvio e arresto del server Importante Quando viene avviato il server DHCP per la prima volta, esso non avrà successo se il file dhcpd.leases non è già esistente. Usate il comando touch / var/lib/dhcp/dhcpd.leases per creare il file nel caso in cui non dovesse esistere. Se lo stesso server esegue BIND come un server DNS, questa fase non risulterà necessaria poichè avviando automaticamente il servizio named, si andrà alla ricerca di un file dhcpd.leases. 82

90 2.4. Relay Agent DHCP Per avviare il servizio DHCP, utilizzate il comando /sbin/service dhcpd start. Per arrestare il server DHCP, utilizzate invece il comando /sbin/service dhcpd stop. Se disponete di più interfacce di rete per il sistema, ma desiderate che il server DHCP si avvii unicamente su di una interfaccia ben specifica, potete configurare il server DHCP per l'avvio solo sul dispositivo in questione. In /etc/sysconfig/dhcpd, aggiungete il nome dell'interfaccia all'elenco DHCPDARGS: # Opzioni della linea di comando DHCPDARGS=eth0 Questo è utile per una macchina firewall con due schede di rete. Una scheda di rete può configurata come client DHCP per recuperare un indirizzo IP in Internet. L'altra scheda di rete può essere usata come un server DHCP per la rete interna protetta dal firewall. Se specificate solo la scheda di rete collegata alla rete interna, otterrete un sistema più sicuro in quanto gli utenti non possono collegarsi al demone tramite Internet. Altre opzioni della linea di comando possono essere specificate nel file /etc/sysconfig/dhcpd e includono: -p <portnum> Specifica il numero di porta UDP sulla quale dhcpd deve essere in ascolto. Il default è la porta 67. Il server DHCP trasmette le risposte ai client DHCP tramite un numero di porta superiore di una unità, a quello specificato per la porta UDP. Per esempio, se si accetta la porta 67, il server si mette in ascolto sulla porta 67 per raccogliere le richieste, mentre utilizza la porta 68 per rispondere al client. Se si specifica una porta e si utilizza il relay agent DHCP, occorre specificare la stessa porta sulla quale il relay agent DHCP è in ascolto. Per maggiori informazioni consultate Sezione 2.4, Relay Agent DHCP. -f Eseguite il demone come processo in primo piano. Questo viene usato soprattutto per operazioni di debug. -d Registrate il demone del server DHCP sul descrittore di errori standard. Questo è usato soprattutto per operazioni di debug. Se non è specificato, il log viene scritto nel file / var/log/messages. -cf <filename> Specificate la posizione del file di configurazione. La posizione di default è /etc/dhcpd.conf. -lf <filename> Specifica la posizione del file del database in affitto. Se il file del database in affitto è già esistente, è importante che lo stesso file venga utilizzato a ogni avvio del server DHCP. Si consiglia di usare questa opzione solo per operazioni di debug su macchine non destinate alla produzione. La posizione di default è /var/lib/dhcpd/dhcpd.leases. -q non stampate l'intero messaggio di copyright quando avviate il demone Relay Agent DHCP Il Relay Agent DHCP (dhcrelay) vi consente di comunicare le richieste DHCP e BOOTP provenienti da una sottorete senza server DHCP a uno o più server DHCP su altre sottoreti. Quando un client DHCP richiede delle informazioni, il Relay Agent inoltra la richiesta all'elenco di server DHCP specificati all'avvio del Relay Agent DHCP. Quando un server DHCP invia una 83

91 3. Configurazione di un client DHCP risposta, viene eseguito il broadcast o l'unicast sulla rete che ha inviato la richiesta originale. Il Relay Agent DHCP ascolta le richieste DHCP su tutte le interfacce a meno che non vengano specificate le interfacce nel file /etc/sysconfig/dhcrelay con la direttiva INTERFACES. Per avviare il Relay Agent DHCP, utilizzate il comando service dhcrelay start. 3. Configurazione di un client DHCP Per configurare manualmente un client DHCP, è necessario modificare il file / etc/sysconfig/network per abilitare il file di networking e di configurazione per ciascun dispositivo di rete nella directory /etc/sysconfig/network-scripts. In questa directory ogni dispositivo dovrebbe avere un file di configurazione chiamato ifcfg-eth0 dove eth0 è il nome del dispositivo di rete. Il file /etc/sysconfig/network dovrebbe contenere la riga seguente: NETWORKING=yes La variabile NETWORKING deve essere impostata su yes per attivare il networking al momento dell,avvio. Il file /etc/sysconfig/network-scripts/ifcfg-eth0 deve contenere le seguenti righe: DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes Sarà necessario un file di configurazione per ogni dispositivo che desiderate configurare per usare il DHCP. Altre opzioni per lo script di rete sono: DHCP_HOSTNAME Usate questa opzione solo se il server DHCP richiede al client di specificare un hostname prima di ricevere un indirizzo IP. (Il demone del server DHCP in Red Hat Enterprise Linux non supporta questo contenuto.) PEERDNS=<answer>, dove <answer> è una delle seguenti: yes Modificare /etc/resolv.conf con le informazioni provenienti dal server. Se si usa DHCP, allora yes è il default. no Non modificate /etc/resolv.conf. SRCADDR=<address>, dove <address> è l'indirizzo IP source specificato per i pacchetti in uscita. USERCTL=<answer>, dove <answer> è una delle seguenti: yes Gli utenti non root sono abilitati al controllo di questo dispositivo. no Gli utenti non root non sono abilitati al controllo di questo dispositivo. 84

92 4. Risorse aggiuntive Se preferite una interfaccia grafica, consultate Capitolo 2, Configurazione di rete su come usare il Network Administration Tool per configurare una interfaccia di rete in modo da utilizzaredh- CP. Suggerimento Per configurazioni avanzate delle opzioni del client DHCP, come ad esempio il protocol timing, i requisiti dell'affitto, le richieste, il supporto DNS dinamico, gli alias insieme ad una vasta gamma di valori da sovrascrivere ed aggiungere alle configurazioni del client, consultare le pagine man di dhclient e dhclient.conf 4. Risorse aggiuntive Per opzioni di configurazione aggiuntive consultare le seguenti risorse Documentazione installata Pagina man di dhcpd Descrive il funzionamento del demone DHCP. Pagina man di dhcpd.conf Spiega come configurare il file di configurazione di DHCP con alcuni esempi. Pagina man di dhcpd.leases Spiega come configurare il file degli affitti DHCP con alcuni esempi. Pagina man di dhcp-options Spiega la sintassi per dichiarare le opzioni DHCP in dhcpd.conf; con alcuni esempi. Pagina man di dhcrelay Spiega il Relay Agent DHCP e le opzioni di configurazione. /usr/share/doc/dhcp-<version>/ Contiene i file di esempio, README, e le note di rilascio per le versioni attuali del servizio DHCP. 85

93 Capitolo 6. FTP File Transfer Protocol (FTP) è uno dei protocolli più vecchi e usati in Internet. Il suo compito è quello di trasferire i file tra host su di una rete in modo sicuro, senza richiedere all'utente di eseguire un log direttamente nell'host remoto o di sapere come usare il sistema remoto. Esso permette agli utenti di accedere i file su sistemi remoti, usando un insieme di comandi molto semplici. Questo capitolo riporta le informazioni di base del protocollo FTP, insieme alle opzioni di configurazione per il server FTP primario presente con Red Hat Enterprise Linux, vsftpd. 1. Il File Transport Protocol Tuttavia, poichè FTP è prevalentemente presente su Internet, viene richiesto spesso di condividere alcuni file con il pubblico. Gli amministratori del sistema, dovrebbero essere a conoscenza delle caratteristiche uniche del protocollo FTP Porte multiple, Modalità multiple Diversamente dai protocolli usati su Internet, FTP necessita di porte di rete multiple per funzionare in modo corretto. Quando una applicazione del client FTP inizia un collegamento ad un server FTP, verrà aperta sul server la porta 21 conosciuta come porta di comando. Questa porta viene usata per emettere tutti i comandi al server. Qualsiasi dato richiesto dal server, viene ritornato al client tramite una porta dati. Il numero della porta per i collegamenti dei dati e il modo con il quale i suddetti collegamenti vengono inizializzati, varia a seconda se il client richiede i dati in modalità attiva o passiva. Di seguito viene riportata la descrizione delle suddette modalità: modalità attiva La modalità attiva è il metodo originale usato dal protocollo FTP per il trasferimento dei dati all'applicazione del client. Quando il trasferimento dei dati della modalità attiva viene iniziato dal client FTP, il server apre un collegamento dalla porta 20 sul server per l'indirizzo IP, e una porta non privilegiata randomica (maggiore di 1024) specificata dal client. Questo significa che la macchina del client deve essere abilitata ad accettare i collegamenti attraverso qualsiasi porta al di sopra di Con la crescita delle reti non sicure, come ad esempio Internet, l'uso dei firewall per proteggere le macchine dei client è molto importante. Poichè questi firewall spesso impediscono i collegamenti in entrata provenienti dai server FTP in modalità attiva, è stato ideata la modalità passiva. modalità passiva La modalità passiva, come quella attiva, viene iniziata dall'applicazione client FTP. Quando si richiedono dati al server, il client FTP indica che desidera accedere ai dati in modalità passiva, e il server fornisce l'indirizzo IP e una porta non privilegiata e randomica (maggiore di 1024) sul server stesso. Il client si collega sulla porta presente sul server, per scaricare le informazioni richieste. Anche se la modalità passiva risolve le problematiche dovute all'interferenza dei firewall del 86

94 2. Sever FTP client con i dati di collegamento, tale modalità può complicare la gestione dei firewall del server. Limitando la gamma di porte non privilegiate offerte per i collegamenti passivi nel file di configurazione del server FTP, rappresenta un modo per limitare il numero di porte aperte su di un server, e semplifica il compito di creazione delle regole del firewall per il server. Consultare Sezione 5.8, Opzioni della rete per maggiori informazioni su come limitare le porte passive. 2. Sever FTP Red Hat Enterprise Linux contiene due diversi server FTP: Red Hat Content Accelerator Un Web server basato sul Kernel che consente di avere un web server e servizi FTP con elevate prestazioni. Poichè la velocità rappresenta la sua prima caratteristica, esso presenta una funzionalità limitata e viene eseguito solo come server FTP anonimo. Per maggiori informazioni su come configurare e gestire Red Hat Content Accelerator, consultare la documentazione disponibile online su vsftpd Un demone FTP sicuro e veloce, il quale rappresenta il server FTP preferito per Red Hat Enterprise Linux. Il remainder di questo capitolo si concentra su vsftpd vsftpd Il Very Secure FTP Daemon (vsftpd) è stato creato per essere veloce, stabile e in modo particolare sicuro. La sua abilità di gestire in modo efficiente e sicuro un gran numero di collegamenti, rappresenta il motivo per il quale vsftpd è il solo FTP 'stand-alone' distribuito con Red Hat Enterprise Linux. Il modello di sicurezza usato da vsftpd presenta tre aspetti primari: Una separazione sostanziale di processi privilegiati e non I suddetti processi gestiscono compiti diversi, e ognuno di questi processi viene eseguito con privilegi minimi necessari per affrontare un compito. I compiti che richiedono privilegi elevati vengono gestiti da processi che richiedono privilegi minimi Facendo leva sullecompatibilità presenti nella libreria libcap, i compiti che generalmente richiedono i privilegi completi di root, possono essere eseguiti in modo più sicuro da un processo con meno privilegi. La maggior parte dei processi vengono eseguiti in una cella chroot Quando possibile, variare la directory root dei processi, sulla directory condivisa; la suddetta directory viene così considerata una cella chroot. Per esempio, se la directory /var/ftp/ risulta essere la directory condivisa primaria, vsftpd assegna nuovamente /var/ftp/ alla nuova directory root, conosciuta come /. Questa operazione non permette alcuna azione da parte di hacker nei confronti di ogni directory non contenuta sotto la nuova directory root. L'uso di queste pratiche di sicurezza provoca i seguenti effetti su come vsftpd affronta queste richieste: 87

95 3. File installati con vsftpd Il processo genitore viene eseguito con il minimo dei privilegi necessari. Il processo genitore calcola dinamicamente il livello dei privilegi necessari per minimizzare il livello di rischio. I processi figli gestiscono l'interazione diretta con i client FTP e vengono eseguiti con il numero più basso possibile di privilegi. Tutte le operazioni che richiedono privilegi elevati, vengono gestite da un processo genitore piccolo. Similmente al server HTTP, vsftpd lancia i processi figli non privilegiati, in modo da gestire i collegamenti in entrata. Ciò permette al processo genitore privilegiato, di essere il più piccolo possibile e di gestire un numero più basso di compiti. Tutte le richieste provenienti dai processi figlio non privilegiati, vengono distribuiti dal processo genitore. Le comunicazioni con i processi figlio vengono ricevute attraverso un socket, e la validità di una informazione provenienti dai processi figlio, viene controllata prima di essere abilitata. Molte interazioni con i client FTP vengono gestite in una cella chroot da processi figlio non privilegiati. Poichè questi processi figlio non sono privilegiati e hanno accesso solo alla directory che è stata condivisa, qualsiasi processo interrotto permette all'aggressore un accesso ai file condivisi. 3. File installati con vsftpd L'RPM vsftpd è in grado d'installare il demone (/usr/sbin/vsftpd), la sua configurazione con i file relativi, e le sue directory FTP sul sistema. Il seguente è un elenco di file e directory maggiormente considerati quando si configura vsftpd: /etc/rc.d/init.d/vsftpd script d'inizializzazione (initscript) usato dal comando / sbin/service per avviare, arrestare o ricaricare vsftpd. Consultate Sezione 4, Avvio e arresto di vsftpd per maggiori informazioni sull'uso di questo script. /etc/vsftpd/vsftpd.conf Il file di configurazione per vsftpd. Consultate Sezione 5, Opzioni di configurazione vsftpd per un elenco di opzioni importanti presenti all'interno di questo file. /etc/vsftpd.ftpusers Un elenco di utenti non abilitati ad eseguire un log in su vsftpd. Per default questo elenco include anche gli utenti root, bin, e daemon. /etc/vsftpd.user_list Questo file può essere configurato in modo da permettere o negare l'accesso agli utenti presenti nell'elenco, a seconda se la direttiva userlist_deny è impostata in /etc/vsftpd/vsftpd.conf su YES (default) o NO. Se /etc/vsftpd.user_list viene usato per garantire l'accesso agli utenti, i nomi degli utenti elencati non devono apparire in / etc/vsftpd.ftpusers. /var/ftp/ Tale directory contiene i file serviti da vsftpd. Essa contiene inoltre la directory /var/ftp/pub/ per gli utenti anonimi. Entrambe le directory sono leggibili da tutti, ma possono essere modificate solo dall'utente root. 4. Avvio e arresto di vsftpd L'RPM vsftpd installa lo script /etc/rc.d/init.d/vsftpd, il quale lo si può accedere usando il 88

96 4.1. Avvio di copie multiple di vsftpd comando /sbin/service. Per avviare il server come utente root, digitare: /sbin/service vsftpd start Per arrestare il server come utente root, digitare: /sbin/service vsftpd stop L'opzione restart rappresenta un modo più semplice per arrestare e riavviare vsftpd. Esso rappresenta il modo più efficiente per confermare i cambiamenti apportati alla configurazione, dopo aver modificato il file di configurazione per vsftpd. Per riavviare il server come utente root digitare: /sbin/service vsftpd restart L'opzione condrestart (conditional restart) avvia solo vsftpd se quest'ultimo è in esecuzione. Questa opzione è utile per gli script, in quanto non avvia il demone se lo stesso non è in esecuzione. Per riavviare il server in modo condizionato come utente root, digitare: /sbin/service vsftpd condrestart 4.1. Avvio di copie multiple di vsftpd Talvolta un solo computer viene usato per servire i domini FTP multipli. Questa tecnica viene chiamata multihoming. Un modo per eseguire tale tecnica, multihome, usando vsftpd, è quello di eseguire delle copie multiple del demone, ognuna delle quali con il proprio file di configurazione. Per fare questo, assegnare prima tutti gli indirizzi IP pertinenti ai dispositivi della rete o dispositivi di rete alias presenti sul sistema. Consultare Capitolo 2, Configurazione di rete per maggiori informazioni sulla configurazione dei dispositivi di rete e dei dispositivi alias. Informazioni aggiuntive sugli script di configurazione della rete sono disponibili nel Capitolo 1, Interfacce di rete. Successivamente, il server DNS per i domini FTP, deve essere configurato in modo da indicare le macchine corrette. Per informazioni su BIND e sui file di configurazione consultare il Capitolo 3, BIND (Berkeley Internet Name Domain). Per far sì che vsftpd risponda alle richieste su diversi indirizzi IP, bisogna eseguire copie multiple del demone. La prima copia deve essere eseguita usando gli initscript vsftpd, come riportato nelsezione 4, Avvio e arresto di vsftpd. Questa copia usa il file di configurazione standard, / etc/vsftpd/vsftpd.conf. Ogni sito FTP aggiuntivo deve avere il file di configurazione con un nome unico nella directory / etc/vsftpd/, come ad esempio /etc/vsftpd/vsftpd-site-2.conf. Ogni file di configurazione deve essere leggibile e scrivibile solo da utenti root. All'interno di ogni file di configurazione per ogni server FTP in ascolto su di una rete IPv4, le seguenti direttive devono essere uniche: listen_address=n.n.n.n 89

97 5. Opzioni di configurazione vsftpd Sostituire N.N.N.N con l'indirizzo IP unico per il sito FTP servito. Se il sito stà usando IPv6, usare invece la direttiva listen_address6. Una volta che ogni server aggiuntivo possiede un file di configurazione, il demone vsftpd deve essere lanciato da un prompt della shell root usando il seguente comando: vsftpd /etc/vsftpd/<configuration-file> [amp ] Nel comando sopra indicato, sostituire <configuration-file> con il nome unico per il file di configurazione del server, come ad esempio /etc/vsftpd/vsftpd-site-2.conf. Altre direttive da alterare in base al server sono: anon_root local_root vsftpd_log_file xferlog_file Per un elenco completo delle direttive disponibili all'interno del file di configurazione di vsftpd, consultare Sezione 5, Opzioni di configurazione vsftpd. Per configurare qualsiasi server aggiuntivo in modo da avviarsi automaticamente al momento dell'avvio, aggiungere il comando sopra citato alla fine del file /etc/rc.local. 5. Opzioni di configurazione vsftpd Anche se vsftpd potrebbe non offrire un livello di personalizzazione offerto da altri server FTP disponibili, esso offre opzioni sufficienti per far fronte a molte delle esigenze di un amministratore. Per questo motivo gli errori di configurazione e quelli programmatici sono limitati. Tutta la configurazione di vsftpd è gestita dal suo file di configurazione, / etc/vsftpd/vsftpd.conf. Ogni direttiva è situata sulla propria riga all'interno del file e segue il formato seguente: <directive>=<value> Per ogni direttiva, sostituire <directive> con una valida direttiva, e <value> con un valore accettato. Importante Non ci deve essere alcun spazio tra <directive>, il simbolo uguale, e <value> in una direttiva. Le righe di commento devono essere precedute dal carattere # e sono ignorate dal demone. 90

98 5.1. Opzioni del demone Per un elenco completo di tutte le direttive disponibili, consultare la pagina man per vsftpd.conf. Il seguente è un elenco di alcune delle direttive più importanti all'interno di / etc/vsftpd/vsftpd.conf. Tutte le direttive non esplicitamente trovate all'interno del file di configurazione di vsftpd, sono impostate nel loro valore di default Opzioni del demone Il seguente è un elenco delle direttive che controllano il comportamento generale del demone vsftpd. listen Quando abilitata, vsftpd viene eseguita in modalità standalone. Red Hat Enterprise Linux imposta questo valore su YES. Questa direttiva non può essere usata insieme con la direttiva listen_ipv6. Il valore di default è NO. listen_ipv6 Quando abilitata, vsftpd viene eseguita in modalità standalone, ma è in ascolto sui socket IPv6. Questa direttiva non può essere usata insieme con la direttiva listen. Il valore di default è NO Opzioni di log in e controlli d'accesso Il seguente è un elenco di direttive le quali controllano il comportamento di login e dei meccanismi di controllo dell'accesso. anonymous_enable Quando abilitata, gli utenti anonimi sono abilitati al log in. Il nome utente anonymous e ftp sono accettati. Il valore di default è YES. Consultare Sezione 5.3, Opzioni per l'utente anonimo per un elenco di direttive che influenzano gli utenti anonimi. banned_ _file Se la direttiva deny_ _enable viene impostata su YES, la stessa specifica il file contenente un elenco di password anonime, le quali non hanno un accesso al server. Il valore di default è /etc/vsftpd.banned_ s. banner_file Specifica il file contenente il testo mostrato quando viene stabilito un collegamento con il server. Questa opzione annulla qualsiasi testo specificato nella direttiva ftpd_banner. Non vi è alcun valore di default per questa direttiva. cmds_allowed Specifica un elenco di comandi delimitati da una virgola abilitati dal server. Tutti gli altri comandi vengono rifiutati. 91

99 5.2. Opzioni di log in e controlli d'accesso Non vi è alcun valore di default per questa direttiva. deny_ _enable Quando abilitata, qualsiasi utente anonimo che utilizza le password delle specificate in /etc/vsftpd.banned_ s non sarà in grado di accedere al server. Il nome del file di riferimento di questa direttiva può essere specificato usando la direttiva banned_ _file. Il valore di default è NO. ftpd_banner Quando abilitata, la stringa specificata all'interno di questa direttiva, viene visualizzata quando viene stabilito un collegamento al server. Questa opzione può essere annullata dalla direttiva banner_file. Per default vsftpd mostra i suoi banner standard. local_enable Quando abilitata, gli utenti locali sono abilitati ad eseguire un log in nel sistema. Il valore di default è YES. Consultare Sezione 5.4, Opzioni dell'utente locale per un elenco di direttive che influenzano gli utenti locali. pam_service_name Specifica il nome del servizio PAM per vsftpd. Il valore di default è ftp. Da notare tuttavia che con Red Hat Enterprise Linux il valore è impostato su vsftpd. Il valore di default è NO. Da notare tuttavia che con Red Hat Enterprise Linux il valore è impostato su YES. userlist_deny Quando usato insieme con la direttiva userlist_enable e impostato su NO, tutti gli utenti locali sono impossibilitati ad eseguire un accesso, a meno che il nome utente non sia presente nel file specificato dalla direttiva userlist_file. Poichè l'accesso viene negato prima di richiedere la password al client, impostando questa direttiva su NO, impedisce agli utenti locali di richiedere una password in modo non cifrato attraverso la rete. Il valore di default è YES. userlist_enable Quando abilitata, gli utenti presenti nel file specificato dalla direttiva userlist_file, non possono eseguire l'accesso. Poichè l'accesso viene negato prima di richiedere la password al client, gli utenti non hanno la necessità di richiedere delle password non cifrate attraverso la rete. Il valore di default è NO, tuttavia con Red Hat Enterprise Linux il valore è impostato su YES. userlist_file Specifica il file indicato da vsftpd, quando è abilitata la direttiva userlist_enable. Il valore di default è /etc/vsftpd.user_list ed è creato durante l'installazione. cmds_allowed Specifica un elenco, separato da una virgola, di comandi FTP abilitati dal server. Qualsiasi altro comando viene rifiutato. 92

100 5.3. Opzioni per l'utente anonimo Non vi è alcun valore di default per questa direttiva Opzioni per l'utente anonimo Il seguente è un elenco di direttive le quali controllano l'accesso al server degli utenti anonimi. Per usare queste opzioni, la direttiva anonymous_enable deve essere impostata su YES. anon_mkdir_write_enable Quando abilitata insieme con la direttiva write_enable, gli utenti anonimi sono in grado di creare nuove directory all'interno di una directory genitore, la quale possiede i permessi di scrittura. Il valore di default è NO. anon_root Specifica i cambiamenti della directory vsftpd, dopo che un utente anonimo ha eseguito il log in. Non vi è alcun valore di default per questa direttiva. anon_upload_enable Quando abilitata insieme con la direttiva write_enable, gli utenti anonimi sono abilitati ad eseguire un upload di file all'interno della directory genitore la quale possiede i permessi di scrittura. Il valore di default è NO. anon_world_readable_only Quando abilitata, gli utenti anonimi possono solo scaricare i file letti da tutti 'world-readable'. Il valore di default è YES. ftp_username Specifica l'account dell'utente locale (riportato in /etc/passwd), usato per un utente FTP anonimo. La home directory specificata in /etc/passwd per l'utente, è la directory root dell'utente FTPanonimo. Il valore di default è ftp. no_anon_password Quando abilitata, non viene richiesta alcuna password all'utente anonimo. Il valore di default è NO. secure_ _list_enable Quando abilitata, viene accettato solo un elenco specificato di password per login anonimi. Ciò rappresenta un modo molto conveniente di offrire una sicurezza limitata per contenuti resi pubblici senza la necessità di utenti virtuali. I login anonimi vengono evitati a meno che la password risulta essere presente nell'elenco / etc/vsftpd. _passwords. Il formato del file è di una password per riga, senza alcuno spazio. Il valore di default è NO Opzioni dell'utente locale 93

101 5.4. Opzioni dell'utente locale Il seguente è un elenco di direttive che caratterizzano il modo di accesso al server dell'utente locale. Per usare queste opzioni, la direttiva local_enable deve essere impostata su YES. chmod_enable Quando abilitata, il comando FTP SITE CHMOD viene abilitato per gli utenti locali. Questo comando permette agli utenti locali di cambiare i permessi presenti sui file. Il valore di default è YES. chroot_list_enable Quando abilitata, gli utenti locali presenti nel file specificato nella direttiva chroot_list_file, vengono posizionati in una cella chroot previo log in. Se abilitata con la direttiva chroot_local_user, gli utenti locali elencati nel file specificato nella direttiva chroot_list_file, non vengono posizionati in una cella chroot dopo il log in. Il valore di default è NO. chroot_list_file Specifica il file contenente un elenco di utenti locali indicati quando la direttiva chroot_list_enable è impostata su YES. Il valore di default è /etc/vsftpd.chroot_list. chroot_local_user Quando abilitata, la directory root verrà cambiata, dopo aver eseguito il log in, nella home directory degli utenti locali. Il valore di default è NO. Avvertimento Abilitando chroot_local_user si và incontro a diverse problematiche riguardanti la sicurezza, in special modo per utenti che possiedono dei privilegi di upload. Per questo motivo tale configurazione non è consigliata. guest_enable Quando abilitata, tutti gli utenti che non sono anonimi, vengono registrati come utenti guest, i quali rappresentano gli utenti locali specificati nella direttiva guest_username. Il valore di default è NO. guest_username Specifica il nome utente sul quale viene mappato l'utente guest. Il valore di default è ftp. local_root Specifica il cambiamento della directory di vsftpd dopo che l'utente locale ha eseguito il log in. Non vi è alcun valore di default per questa direttiva. local_umask Specifica il valore di umask per la creazione di un file. Da notare che il valore di default viene espresso con un numero ottale 'octal mode' (un sistema numerico basato su otto cifre), il quale include un prefisso "0". In caso contrario il valore viene considerato come un numero intero con base decimale. 94

102 5.5. Opzioni della directory Il valore di default è 022. passwd_chroot_enable Quando abilitata insieme con la direttiva chroot_local_user, viene modificata la directory root vsftpd degli utenti locali in base all'evento della /./ nel campo della home directory all'interno di /etc/passwd. Il valore di default è NO. user_config_dir Specifica il percorso per una directory contenente i file di configurazione che presentano il nome degli utenti locali del sistema, il quale contiene a sua volta le impostazioni specifiche per quell'utente. Qualsiasi direttiva nel file di configurazione dell'utente, annulla quelle trovate in /etc/vsftpd/vsftpd.conf. Non vi è alcun valore di default per questa direttiva Opzioni della directory Il seguente è un elenco di direttive che influenzano le directory. dirlist_enable Quando abilitata, gli utenti possono visualizzare gli elenchi della directory. Il valore di default è YES. dirmessage_enable Quando abilitata, viene visualizzato un messaggio ogni qualvolta un utente inserisce una directory con un file di messaggio. Questo messaggio si trova all'interno della directory che è stata inserita. Il nome di questo file è specificato nella direttiva message_file ed è per default.message. Il valore di default è NO. Da notare tuttavia che con Red Hat Enterprise Linux il valore è impostato su YES. force_dot_files Quando abilitata, i file che iniziano con un punto (.), vengono elencati negli elenchi delle directory, con l'accezione dei file. and.. Il valore di default è NO. hide_ids Quando abilitata, tutti gli elenchi delle directory mostrano ftp come l'utente e il gruppo per ogni file. Il valore di default è NO. message_file Specifica il nome del file di messaggio quando si usa la direttiva dirmessage_enable. Il valore di default è.message. text_userdb_names Quando abilitata, vengono usati i nomi dell'utente e dei gruppi in formato di test, al posto delle voci UID e GID. Abilitando questa opzione potrebbe rallentare le prestazioni del server. Il valore di default è NO. use_localtime Quando abilitata, gli elenchi della directory rivelano l'orario locale per il 95

103 5.6. Opzioni di trasferimento del file computer invece dell'orario GMT. Il valore di default è NO Opzioni di trasferimento del file Il seguente è un elenco di direttive che influenzano le directory. download_enable Quando abilitata, è possibile scaricare i file. Il valore di default è YES. chown_uploads Quando abilitata, tutti i file caricati dagli utenti anonimi, sono posseduti dall'utente specificato nella direttiva chown_username. Il valore di default è NO. chown_username Specifica il proprietario dei file caricati anonimamente, se si abilita la direttiva chown_uploads. Il valore di default è root. write_enable Quando abilitata, sono abilitati i comandi FTP che possono modificare il file system, come ad esempio DELE, RNFR, e STOR. Il valore di default è YES Opzioni di Logging Il seguente è un elenco di direttive che influenzano il comportamento di vsftpd durante un logging. dual_log_enable Quando abilitata insieme con xferlog_enable, vsftpd registra contemporaneamente due file: un log wu-ftpd-compatibile per il file specificato nella direttiva xferlog_file (/var/log/xferlog per default) e un file log standard vsftpd specificato nella direttiva vsftpd_log_file (/var/log/vsftpd.log per default). Il valore di default è NO. log_ftp_protocol Quando abilitato insieme con xferlog_enable e con xferlog_std_format impostato su NO, vengono registrati tutti i comandi FTP e le risposte. Questa direttiva è utile per il debugging. Il valore di default è NO. syslog_enable Quando abilitata insieme con xferlog_enable, tutti i logging registrati normalmente sul file log vsftpd standard specificato nella direttiva vsftpd_log_file (/ var/log/vsftpd.log per default), vengono inviati al sistema che li registra invece della facility FTPD. Il valore di default è NO. vsftpd_log_file Specifica il file log vsftpd. Per usare questo file, xferlog_enable deve es- 96

104 5.8. Opzioni della rete sere abilitato e xferlog_std_format deve essere impostato su NO o, se si imposta xferlog_std_format su YES, dual_log_enable deve essere abilitato. È importante notare che se syslog_enable è impostato su YES, viene usato il sistema di log, invece del file specificato in questa direttiva. Il valore di default è /var/log/vsftpd.log. xferlog_enable Quando abilitata, vsftpd registra i collegamenti (solo in formato vsftpd) e le informazioni di trasferimento del file sul file log specificato nella direttiva vsftpd_log_file (per default /var/log/vsftpd.log). Se xferlog_std_format è impostato su YES, vengono registrate solo le informazioni sul trasferimento del file e non i collegamenti, e viene usato il file log specificato in xferlog_file (/var/log/xferlog per default). È importante notare che entrambi i file log ed i formati log vengono usati se dual_log_enable è impostato su YES. Il valore di default è NO. Da notare tuttavia che con Red Hat Enterprise Linux il valore è impostato su YES. xferlog_file Specifica il file log wu-ftpd-compatibile. Per usare questo file, bisogna abilitare xferlog_enable, e xferlog_std_format deve essere impostato su YES. Esso viene anche usato se dual_log_enable è impostato su YES. Il valore di default è /var/log/xferlog. xferlog_std_format Quando abilitata insieme con xferlog_enable, viene registrato, sul file specificato nella direttiva xferlog_file, solo un log di tresferimento del file wu-ftpdcompatibile (/var/log/xferlog per default). È importante notare che questo file registra solo i trasferimenti del file e non registra i collegamenti al server. Il valore di default è NO. Da notare tuttavia che con Red Hat Enterprise Linux il valore è impostato su YES. Importante Per mantenere una compatibilità con i file log scritti dal server FTP wu-ftpd più vecchio, la direttiva xferlog_std_format è impostata su YES con Red Hat Enterprise Linux. Tuttavia, questa impostazione significa che i collegamenti al server non sono registrati. Per eseguire un log dei collegamenti in formato vsftpd e gestire un log di trasferimento del file wu-ftpd-compatibile, impostare dual_log_enable su YES. Se non è importante mantenere un log di trasferimento del file wu-ftpd-compatibile, impostare xferlog_std_format su NO, e commentare la riga con un carattere #, oppure cancellare l'intera riga Opzioni della rete Il seguente è un elenco di direttive che influenzano il modo con il quale vsftpd interagisce con la rete. 97

105 5.8. Opzioni della rete accept_timeout Specifica la quantità di tempo per un client, nell'uso della modalità passiva, per stabilire un collegamento. Il valore di default è 60. anon_max_rate Specifica la velocità massima di trasferimento dei dati per gli utenti anonimi in byte al secondo. Il valore di default è 0, il quale non limita la velocità di trasferimento. connect_from_port_20 Quando abilitata, vsftpd viene eseguita con privilegi sufficienti per aprire la porta 20 sul server, durante i trasferimenti dei dati in modalità attiva. Disabilitare questa opzione permette a vsftpd di essere eseguito con meno privilegi, ma potrebbe essere non compatibile con alcuni client FTP. Il valore di default è NO. Da notare tuttavia che con Red Hat Enterprise Linux il valore è impostato su YES. connect_timeout Specifica il tempo massimo, in secondi, al quale un client che usa una modalità attiva, deve rispondere per un collegamento dei dati. Il valore di default è 60. data_connection_timeout Specifica il tempo massimo, in secondi, all'interno del quale il trasferimento dei dati può arrestarsi. Una volta azionato, il collegamento al client remoto viene chiuso. Il valore di default è 300. ftp_data_port Specifica la porta usata per i collegamenti attivi dei dati quando connect_from_port_20 è impostato su YES. Il valore di default è 20. idle_session_timeout Specifica il tempo massimo che intercorre tra due comandi da un client remoto. Una volta azionato, il collegamento al client remoto viene chiuso. Il valore di default è 300. listen_address Specifica l'indirizzo IP sul quale vsftpd è in ascolto per i collegamenti di rete. Non vi è alcun valore di default per questa direttiva. Suggerimento Se si eseguono copie multiple di vsftpd servendo indirizzi IP diversi, il file di configurazione per ogni copia del demone vsftpd, deve avere un valore diverso per questa direttiva. Consultare Sezione 4.1, Avvio di copie multiple di vsftpd per maggiori informazioni sui server FTP 'multihomed'. 98

106 5.8. Opzioni della rete listen_address6 Specifica l'indirizzo IPv6 sul quale vsftpd è in ascolto per i collegamenti di rete, quando listen_ipv6 è impostato su YES. Non vi è alcun valore di default per questa direttiva. Suggerimento Se si eseguono copie multiple di vsftpd servendo indirizzi IP diversi, il file di configurazione per ogni copia del demone vsftpd, deve avere un valore diverso per questa direttiva. Consultare Sezione 4.1, Avvio di copie multiple di vsftpd per maggiori informazioni sui server FTP 'multihomed'. listen_port Specifica la porta sulla quale vsftpd è in ascolto per i collegamenti di rete. Il valore di default è 21. local_max_rate Specifica la velocità massima di trasferimento dei dati, in byte al secondo, per utenti locali registrati nel server. Il valore di default è 0, il quale non limita la velocità di trasferimento. max_clients Specifica il numero massimo di client simultanei che si possono collegare al server, quando lo stesso è in esecuzione in modalità 'standalone'. Qualsiasi altro collegamento client aggiuntivo causerà la generazione di un messaggio di errore. Il valore di default è 0, il quale non limita i collegamenti. max_per_ip Specifica il numero massimo di client che si possono collegare dallo stesso indirizzo IP della sorgente. Il valore di default è 0, il quale non limita i collegamenti. pasv_address Specifica l'indirizzo IP per l'indirizzo IP 'public facing' del server, per i server situati dietro i firewall Network Address Translation (NAT). Ciò abilita vsftpd a fornire l'indirizzo di ritorno corretto per i collegamenti in modalità passiva. Non vi è alcun valore di default per questa direttiva. pasv_enable Quando abilitata, sono permessi i collegamenti in modalità passiva. Il valore di default è YES. pasv_max_port Specifica la porta più alta inviata ai client FTP per i collegamenti in modalità passiva. Questa impostazione viene usata per limitare la gamma della porta, in modo da semplificare la creazione delle regole del firewall. Il valore di default è 0, il quale non limita la gamma della porta passiva più alta. Il valore non deve eccedere pasv_min_port Specifica la porta più bassa inviata ai client FTP per i collegamenti in modalità passiva. Questa impostazione viene usata per limitare la gamma della porta, in modo 99

107 6. Risorse aggiuntive da semplificare la creazione delle regole del firewall. Il valore di default è 0, il quale non limita la gamma della porta passiva più bassa. Il valore non deve essere minore di pasv_promiscuous Quando abilitata, i collegamenti dei dati non vengono controllati in modo da assicurare che gli stessi siano originati dallo stesso indirizzo IP. Questa impostazione è utile solo per alcuni tipi di tunneling. Attenzione Non abilitate questa opzione se non è necessario, in quanto essa disabilita un contenuto di sicurezza molto importante, il quale verifica che i collegamenti in modalità passiva siano originati dallo stesso indirizzo IP del collegamento di controllo che inizia il trasferimento dei dati. Il valore di default è NO. port_enable Quando abilitata, sono permessi i collegamenti in modalità attiva. Il valore di default è YES. 6. Risorse aggiuntive Per maggiori informazioni su vsftpd, consultate le seguenti risorse Documentazione installata Directory /usr/share/doc/vsftpd-<version-number>/ Sostituire <version-number> con la versione installata del pacchetto vsftpd. Questa directory contiene un file README con informazioni di base sul software. Il file TUNING contiene alcuni suggerimenti sulla regolazione della prestazione di base e la directory SECURITY/ la quale contiene le informazioni sul modello di sicurezza impiegato da vsftpd. Pagine man relative a vsftpd Sono disponibili un certo numero di pagine man per il demone ed i file di configurazione. Il seguente è un elenco di alcune delle più importanti pagine man. Applicazioni del server man vsftpd Descrive le opzioni della linea di comando disponibili per vsftpd. File di configurazione man vsftpd.conf Contiene un elenco dettagliato di opzioni disponibili all'interno del file di configurazione per vsftpd. 100

108 6.2. Siti web utili man 5 hosts_access Descrive il formato e le opzioni disponibili all'interno dei file di configurazione dei wrapper TCP: hosts.allow e hosts.deny Siti web utili La pagina del progetto vsftpd è molto utile per trovare la documentazione più recente e per contattare l'autore del software. Questo sito web fornisce una breve spiegazione delle differenze tra un FTP in modalità attiva e passiva. Un elenco completo di Request for Comments (RFC) 'Richiesta di commenti', relativi al protocollo FTP da IETF. 101

109 Parte II. Configurazione del sistema Uno dei compiti di un amministratore di sistema è quello di configurare il sistema stesso in modo da svolgere compiti particolari, per diversi tipi di utenti e per diverse configurazioni hardware. Questa sezione spiega come configurare un sistema Red Hat Enterprise Linux.

110 Capitolo 7. Configurazione del sistema X Window Durante l'installazione, il monitor del sistema, la scheda video e le impostazioni del display sono configurati. Per cambiare una di queste impostazioni, usare lo &RHXFREE86TOOL;. Per iniziare lo &RHXFREE86TOOL;, selezionare System (on the panel) => Amministrazione => Display, oppure digitare il comando system-config-display ad un prompt della shell (per esempio, in un terminale XTerm o GNOME). Se il sistema X Window non è in esecuzione, viene avviata una versione più piccola di X per eseguire il programma. Dopo aver effettuato un cambiamento delle impostazioni, abbandonate il desktop grafico ed effettuate nuovamente un log in per confermare i cambiamenti. 1. Impostazioni del display Il pannello Impostazioni permette agli utenti di cambiare la risoluzione e la profondità del colore. Il display di un monitor consiste in tanti piccoli punti chiamati pixel. Il numero di pixel visualizzato nello stesso istante è chiamato risoluzione. Per esempio, la risoluzione 1024x768 significa che vengono usati 1024 pixel in orizzontale, e 768 pixel verticale. Più elevati sono i numeri inerenti la risoluzione, e migliore sarà la qualità dell'immagine mostrata dal monitor. La profondità del colore del display determina il numero di colori visualizzati. Più alta è la profondità del colore, maggiore è il contrasto tra i colori. 103

111 2. Impostazioni hardware del display Figura 7.1. Impostazioni del display 2. Impostazioni hardware del display Quando l'applicazione &RHXFREE86TOOL; viene avviata, vengono verificati sia la scheda video che il monitor. Se si verifica l'hardware in modo corretto, le sue informazioni verranno visualizzate sulla tabella Hardware come mostrato in Figura 7.2, Impostazioni hardware del display. 104

112 3. Impostazioni del display Dual Head Figura 7.2. Impostazioni hardware del display Per cambiare il tipo di monitor o qualsiasi sue impostazioni, fate clic sul pulsante Configura corrispondente. Per cambiare il tipo di scheda video o qualsiasi sue applicazioni, fate clic sul pulsante Configura vicino alle proprie impostazioni. 3. Impostazioni del display Dual Head Se sono state installate schede video multiple, il supporto per il monitor dual head sarà disponibile e verrà configurato tramite la tabella Dual head come mostrato in Figura 7.3, Impostazioni del display Dual Head. 105

113 3. Impostazioni del display Dual Head Figura 7.3. Impostazioni del display Dual Head Per abilitare l'utilizzo del Dual Head controllate la casella relativa Utilizza dual head. Per configurare il secondo tipo di monitor, fate clic sul pulsante Configura. Potrete altresì configurare le altre impostazioni Dual Head utilizzando l'elenco a tendina corrispondente. Per l'opzione Layout del Desktop, selezionando Desktop espansi permetterà ad entrambi i monitor di utilizzare uno spazio di lavoro più grande. Selezionando invece Desktop individuali verrà condiviso il mouse e la tastiera fra i display, ma limita le finestre ad un singolo display. 106

114 Parte III. Sicurezza ed autenticazione Tenendo presente che gli amministratori di sistema hanno bisogno di rendere sicuri i propri sistemi mission-critical, i propri servizi e/o dati, Red Hat Enterprise Linux fornisce un vasta gamma di tool e di metodi, che fanno parte di una strategia di sicurezza completa. Questo capitolo fornisce una introduzione generale sulla sicurezza, ed in modo particolare da una prospettiva specifica di Red Hat Enterprise Linux. Fornisce vari concetti nelle aree di valutazione della sicurezza, punti deboli comuni, e metodi di reazione in risposta agli incidenti ed alle intrusioni. Altresi, fornisce informazioni specifiche e semplici concetti riguardanti la configurazione su come usare SELinux, in modo da rendere più sicuri la Workstation, il Server, VPN, il firewall ed altri tipi d'implementazione. Questo capitolo richiede una conoscenza di base sulla sicurezza IT, e di conseguenza fornisce solo una copertura minima di pratiche comuni come ad esempio il controllo dell'accesso fisico, procedure e policy sulla gestione degli account ecc. Quando consentito, vengono indicati riferimenti a risorse ed informazioni esterne.

115 Capitolo 8. Panoramica sulla sicurezza A causa del continuo ricorso a potenti computer che aiutano le aziende nella loro gestione e nel mantenimento delle informazioni del proprio personale, le aziende del settore hanno potuto creare una pratica molto importante, e cioè quella di rendere sicure le loro reti ed i loro computer. Le imprese hanno stimolato la conoscenza e l'abilità degli esperti sulla sicurezza, e conseguentemente a verificare propriamente i sistemi ed adattare le soluzioni per far fronte ai requisiti operativi dell'organizzazione stessa. A causa di queste organizzazioni, di natura molto dinamiche e che consentono l'accesso ai propri dipendenti alle risorse IT sia in modo remoto che in modo locale, la necessità di avere degli ambienti informatici sicuri è diventata sempre più rilevante. Sfortunatamente, molte organizzazioni (così come singoli utenti) considerano il fattore sicurezza come un fattore secondario, un processo che si può trascurare in favore dell'aumento della potenza, della produttività, e delle considerazioni di carattere finanziario. Una sua implementazione, viene spesso intrapresa postmortem cioè dopo il verificarsi di una intrusione da parte di un utente non autorizzato. Gli esperti nel campo della sicurezza, concordano che le misure più idonee sono quelle prese prima del collegamento ad una rete non fidata, come ad esempio Internet, tale provvedimento aiuta in modo efficace a contrastare i tentativi d'intrusione. 1. Valutazione dei punti deboli Se un cracker ha a disposizione tempo sufficiente, risorse, e motivazioni, sarà in grado di introdursi in quasi ogni sistema. Alla fine dei conti, tutte le procedure di sicurezza e le tecnologie attualmente disponibili, non possono garantirvi la totale sicurezza dei vostri sistemi. I router sono in grado di rendere sicuri i gateway nei confronti di Internet. I firewall vi aiuteranno a rendere sicuri i confini della vostra rete. I Virtual Private Network renderanno possibile e sicuro il passaggio dei vostri dati attraverso un flusso cifrato. Gli Intrusion detection system, hanno l'abilità di avvisarvi della presenza di attività maliziosa. Tuttavia, il successo di tutti questi mezzi di deterrenza, dipendono da un certo numero di variabili che includono: L'esperienza dei membri responsabili alla configurazione, al controllo e mantenimento di queste tecnologie. L'abilità di emettere patch e aggiornare i servizi e i kernel in modo veloce ed efficiente. L'abilità del personale preposto, a mantenere un costante controllo della rete. A causa dello stato dinamico della capacità dei sistemi di conservare i dati e le tecnologie, rendere sicure le vostre risorse corporative può essere un compito complesso. A causa di questa complessità, potrebbe risultare difficile trovare risorse idonee per tutti i vostri sistemi. Mentre è possibile avere del personale la cui conoscenza informatica è in grado di coprire molte aree riguardanti la sicurezza, risulta difficile trattenere personale esperto in più aree. Questo perchè ogni area richiede una concentrazione e un'attenzione costante, in quanto essa è in continua evoluzione. Le informazioni sulla sicurezza non restano invariate. 108

116 1.1. Pensare come il nemico 1.2. Definizione di valutazione e di prova Supponete di gestire una rete di tipo enterprise. Tali reti generalmente includono sistemi operativi, applicazioni, server, monitor di rete, firewall, intrusion detection system e molto altro. Immaginate ora di cercare di tenervi aggiornati su tutti questi sistemi. Data la complessità degli ambienti di networking e dei software moderni, exploit e bug possono rappresentare purtroppo una costante. Mantenersi aggiornati con patch e altri cambiamenti su di una rete, può risultare un compito non facile, in particolar modo in una grande organizzazione con sistemi eterogenei. La combinazione tra l'esperienza necessaria e il compito di mantenersi aggiornati su di un gran numero di sistemi, facilita il verificarsi di incidenti, i sistemi vengono violati, i dati corrotti e i servizi interrotti. Per migliorare le tecnologie riguardanti la sicurezza, quindi proteggere sistemi, reti e dati, pensate come un cracker, verificate la sicurezza dei sistemi andando alla ricerca della vulnerabilità. La ricerca di queste vulnerabilità all'interno dei vostri sistemi e delle risorse della rete, può aiutarvi ad evidenziare eventuali carenze nel vostro apparato di sicurezza, dandovi la possibilità di far fronte a tali problemi prima che un cracker possa fare danni. Se effettuate una verifica della vostra abitazione, ovviamente controllerete se ogni porta sia chiusa. Controllerete ogni finestra assicurandovi che esse siano ben chiuse. Lo stesso concetto viene applicato per i sistemi, le reti e per i dati elettronici. Gli utenti maliziosi rappresentano i ladri dei vostri dati. Concentratevi sui loro strumenti, sulla loro mentalità, e sulle loro motivazioni in modo tale da poter reagire con successo ad eventuali loro azioni Definizione di valutazione e di prova È necessario distinguere i vari modi di valutazione della vulnerabilità. Le valutazioni possono essere suddivise in: Controllo esterno e controllo interno. Quando si effettua un controllo esterno, non farete altro che cercare di compromettere i vostri sistemi dall'esterno. Trovandovi all'esterno avrete lo stesso punto di vista che si presenta ad un cracker. Vedrete quello che un cracker vede indirizzi IP publicly-routable, i sistemi sul vostro DMZ, interfacce esterne del vostro firewall e molto altro. DMZ è l'acronimo di "demilitarized zone", il quale corrisponde ad un computer oppure ad una sottorete minore che si trova tra una rete interna fidata, come ad esempio una LAN privata corporativa, e una rete esterna non fidata, come ad esempio può essere internet. Generalmente DMZ contiene dei dispositivi accessibili al traffico di internet, come ad esempio Web (HTTP ) server, server FTP, SMTP ( ) server e server DNS. Quando effettuate un controllo interno invece, vi troverete in una condizione di vantaggio in quanto considerati utenti fidati. Questo tipo di controllo vi fornirà il vostro punto di vista e quello dei vostri colleghi, una volta effettuata la registrazione sui vostri sistemi. Potrete vedere i server di stampa, i file server, i database e altre risorse. Sono presenti delle distinzioni tra questi due tipi di valutazione. Trovandovi all'interno avrete maggiori privilegi rispetto ad un utente esterno. Ancora oggi in molte organizzazioni la sicurezza viene configurata in modo tale da mantenere gli intrusi all'esterno. Molto poco viene fatto per mantenere una maggiore sicurezza da attacchi interni (firewall dipartimentali, controllo dell'accesso livello-utente, procedure di autenticazione per risorse interne, e molto altro). Generalmente sono disponibili numerose risorse quando si effettua un controllo dall'interno, questo 109

117 1.2. Definizione di valutazione e di prova perchè molti sistemi sono interni alla compagnia. Una volta posizionati all'esterno, vi sarà dato uno stato di utente non fidato. I sistemi e le risorse disponibili esternamente sono generalmente limitati. È importante considerare la differenza tra una valutazione della vulnerabilità e le prove di penetrazione. Pensate ad una valutazione della vulnerabilità come il primo passo verso una prova di penetrazione. Le informazioni ottenute dalla valutazione, saranno usate durante la prova. Mentre la valutazione và alla ricerca di buchi e potenziali punti deboli, la prova di penetrazione cerca di sfruttare i risultati. L'assegnazione di infrastrutture di rete, rappresenta un processo dinamico. La sicurezza, sia dell'informazione e sia fisica, è dinamica. Effettuando una valutazione, si può ottenere una panoramica, la quale può essere falso positivo e falso negativo. Gli amministratori responsabili risultano essere idonei solo in base agli strumenti da loro usati e alla loro conoscenza. Prendete qualsiasi strumento di valutazione attualmente disponibile, usatelo sul vostro sistema, e quasi sicuramente vi saranno dei falsi-positivi. Sia a causa dell'utente che a causa di un errore del programma, il risultato è identico. Il tool potrebbe essere in grado di trovare dei punti deboli che in realtà non esistono (falso-positivo); o ancora peggio, lo strumento non trova alcun punto debole quando in realtà essi sono esistenti (falso-negativo). Una volta definite le differenze tra la valutazione della vulnerabilità e la prova di penetrazione, è sempre buona pratica prendere i risultati della valutazione e controllarli accuratamente prima di effettuare una prova di penetrazione. Avviso Se cercate di sfruttare i punti deboli delle risorse di produzione, si può incorrere a spiacevoli risultati nei confronti della produttività ed efficienza dei vostri sistemi e della rete. Il seguente elenco riporta alcuni dei benefici che si possono ottenere effettuando delle valutazioni dei vari punti deboli. Crea un coinvolgimento proattivo nei confronti della sicurezza delle informazioni Trova potenziali exploit prima dei cracker Ne risualta in un aggiornamento dei sistemi e patch correlate Promuove la crescita e aiuta lo sviluppo della competenza del personale Riduce la perdita economica e la pubblicità negativa Stabilire una metodologia Per assistere alla selezione dei tool per la valutazione della vulnerabilità, è consigliato stabilire una metodologia di valutazione. Sfortunatamente, non vi è alcuna metodologia predefinita o approvata in questo momento, senso comune e pratica sono sufficienti a questo scopo. 110

118 1.3. Valutazione degli strumenti Qual'è l'obbiettivo? Stiamo cercando un solo server, oppure una intera rete e qualsiasi cosa presente al suo interno? Siamo esterni o interni alla compagnia? Le risposte a queste domande sono importanti, in quanto vi aiuteranno non solo a selezionare gli strumenti ma anche a scegliere il modo per usarli. Per saperne di più su come stabilire delle metodologie, consultate i seguenti siti web: Open Source Security Testing Methodology Manual (OSSTMM) Open Web Application Security Project 1.3. Valutazione degli strumenti Un processo di valutazione può iniziare usando una forma di strumento di raccolta delle informazioni. Quando si controlla l'intera rete, identificate prima la struttura,in modo da poter trovare gli host in esecuzione. Una volta identificati, esaminate ogni host in modo individuale. Per fare ciò, avrete bisogno di un altro set di strumenti. Sapere quale strumento dovete usare rappresenta una fase cruciale nel trovare i punti deboli. Proprio come in qualsiasi aspetto della vita quotidiana, ci sono un gran numero di tool capaci di eseguire gli stessi lavori. Lo stesso concetto viene applicato anche per effettuare una valutazione della sicurezza. Ci sono tool specifici per i diversi sistemi operativi, per le applicazioni ed anche per le reti (basate su protocolli usati). Alcuni tool non sono a pagamento mentre altri si. Alcuni sono facili da usare, mentre altri sono poco documentati e difficili da usare, ma hanno in compenso dei contenuti che altri non hanno. Trovare gli strumenti giusti può rappresentare un compito difficile, quello che conta alla fine è l'esperienza. Se possibile, impostate un 'laboratorio' e provate un maggior numero di strumenti possibile, annotando le qualità ma anche i loro punti deboli.ricontrollate il file README o le pagine man in questione. In aggiunta, per maggiori informazioni controllate Internet, ad esempio gli articoli, manuali passo-dopo-passo, oppure le mailing list specifiche di uno strumento. Gli strumenti di seguito riportati, sono solo alcuni esempi di strumenti disponibili Lettura degli host con Nmap Nmap è un tool molto diffuso ed è incluso in Red Hat Enterprise Linux, può essere usato per determinare la disposizione di una rete. Nmap è disponibile ormai da molti anni ed è probabilmente il tool più usato per la raccolta delle informazioni. È inclusa anche una eccellente pagina man, capace di fornire una descrizione dettagliata delle sue opzioni e del suo uso. Gli amministratori possono usare Nmap su di una rete, per trovare sistemi host e per aprire delle porte. Nmap rappresenta un primo passo corretto per la valutazione della vulnerabilità. Potete tracciare tutti gli host all'interno della vostra rete, e addirittura passare una opzione capace di permettere Nmap, di identificare il sistema operativo in esecuzione su di un host particolare. Nmap è una buona base per stabilire un criterio d'uso dei servizi sicuri e arrestare quelli non usati Uso di Nmap Nmap può essere eseguito da un prompt della shell digitando il comando nmap seguito 111

119 1.3. Valutazione degli strumenti dall'hostname o dall'indirizzo IP della macchina che desiderate controllare. nmap foo.example.com I risultati di questo controllo (il quale può richiedere anche qualche minuto, depende dalla posizione dell'host) dovrebbe assomigliare al seguente: Starting nmap V ( ) Interesting ports on localhost.localdomain ( ): (T Nmap verifica le porte di comunicazione di rete in ascolto più usate o in attesa dei servizi. Questa conoscenza può essere utile per un amministratore che desidera terminare i servizi non necessari. Per maggiori informazioni sull'uso di Nmap, consultate la homepage al seguente URL: Nessus Nessus è uno scanner completo per la sicurezza del servizio. L'architettura plug-in di Nessus permette agli utenti di personalizzarlo per i loro sistemi, e per le loro reti. Come con qualsiasi scanner, Nessus è idoneo tanto quanto il database della firma sul quale fà affidamento. Fortunatamente, Nessus viene costantemente aggiornato, esso contiene un rapporto esteso, verifica host, e ricerca la vulnerabilità in tempo reale. Ricordatevi che possono esserci falsi positivi e falsi negativi, anche su di uno strumento potente e aggiornato come Nessus. Nota Nessus non è incluso ne supportato da Red Hat Enterprise Linux. È stato incluso in questo documento solo come riferimento per gli utenti interessati al suo impiego. Per maggiori informazioni su Nessus, consultate la homepage al seguente URL: Nikto Nikto è un eccellente scanner script (CGI) common gateway interface. Ha la capacità non solo di controllare eventuali vulnerabilità CGI, ma anche di effettuare questo controllo in modo da eludere gli intrusion detection system. È accompagnato da una eccellente documentazione la quale deve essere consultata attentamente prima di eseguire il programma. Se avete un certo numero di Web server in grado di fornire script CGI, Nikto può diventare una risorsa eccellente per il controllo della sicurezza di questi server. Nota Nikto non è incluso ne supportato da Red Hat Enterprise Linux. È stato incluso in questo documento solo come riferimento per gli utenti interessati al suo uso. 112

120 2. Aggiornamenti sulla sicurezza Maggiori informazioni su Nikto sono disponibili sul seguente URL: Lo scanner VLAD VLAD è uno scanner per le vulnerabilità sviluppato dal team RAZOR a Bindview, Inc., viene usato per il controllo della SANS Top Ten list dei problemi più comuni sulla sicurezza (problematiche inerenti SNMP, condivisione dei file, ecc). Anche se non presenta tanti contenuti quanti ne possiede Nessus, vi consigliamo ugualmente di consultarlo. Nota VLAD non è incluso ne supportato da Red Hat Enterprise Linux. È stato incluso in questo documento solo come riferimento per gli utenti interessati al suo uso. Sono disponibili maggiori informazioni su VLAD sul sito web del team RAZOR al seguente URL: Anticipazione delle vostre necessità future Sono disponibili, a seconda del vostro obbiettivo e delle vostre risorse, molti tool. Ci sono strumenti per reti wireless, reti Novel, sistemi Windows, sistemi Linux e molti altri. Un'altra fase essenziale per l'effettuazione di una valutazione, può essere la revisione della sicurezza fisica, il controllo del personale, o la verifica di rete PBX/voice. Stanno emergendo nuovi concetti, come ad esempio war walking, per il controllo del perimetro delle vostre strutture fisiche enterprise per la vulnerabilità di rete wireless. Essi rappresentano solo alcuni di questi concetti emergenti che potete investigare e, se necessario, incorporare nelle vostre verifiche. L'immaginazione e l'esposizione sono i soli limiti di una pianificazzione e di una conduzione delle valutazioni sulla vulnerabilità. 2. Aggiornamenti sulla sicurezza Una volta scoperte le vulnerabilità di un sistema, il software interessato deve essere aggiornato in modo da evitare potenziali rischi. Se il pacchetto fà parte della distribuzione Red Hat Enterprise Linux ed è supportato, Red Hat, Inc. emette, appena possibile, alcuni pacchetti aggiornati in grado di risolvere i problemi riguardanti la sicurezza. Spesso la verifica di un exploit viene accompagnata da una patch (o da un source code capace di risolvere il problema). La patch viene applicata al pacchetto di Red Hat Enterprise Linux, provato dal team Red Hat che ne assicura la qualità, ed emesso come un aggiornamento errata. Se la patch viene a mancare, allora uno sviluppatore di Red Hat lavorerà insieme con il tecnico responsabile del pacchetto, per la risoluzione del problema. Dopo aver risolto tale problema, il pacchetto viene provato, emettendo così un errata update. Se è stato rilasciato un aggiornamento dell'errata riguardante il software sul vostro sistema, è consigliato effettuare un aggiornamento dei pacchetti in questione appena possibile, questo per minimizzare il periodo nel quale il vostro sistema può essere vulnerabile. 113

121 2.1. Aggiornare i pacchetti 2.1. Aggiornare i pacchetti Quando si esegue un aggiornamento software di un sistema, è importante scaricare la versione aggiornata da una fonte fidata. Un aggressore è in grado di ricostruire facilmente un pacchetto con lo stesso numero della versione del pacchetto preposto per la soluzione dei problemi, ma con un exploit diverso presente nel suo interno, immettendolo così su Internet. Se si verifica quanto sopra descritto, l'uso delle misure di sicurezza come ad esempio il controllo dei file con l'rpm originale, non sarà sufficiente a rilevare l'exploit. Per questo motivo è molto importante scaricare gli RPM da fonti fidate come ad esempio Red Hat, Inc., e controllare la firma del pacchetto, per assicurarsi che lo stesso sia stato costruito dalla fonte. Red Hat offre due modi per ottenere informazioni sugli errata updates: 1. Elencati e disponibili per il download su Red Hat Network 2. Elencati ma non disponibili sul sito web Red Hat Errata Nota bene Iniziando con la gamma Red Hat Enterprise Linux, i pacchetti aggiornati possono essere scaricati solo da Red Hat Network. Anche se il sito web Red Hat Errata contiene le informazioni aggiornate, esso non contiene i pacchetti attuali per il download Come usare Red Hat Network Red Hat Network vi permette di automatizzare molti dei processi di aggiornamento. Determina quali pacchetti RPM sono necessari al vostro sistema, li scarica da un luogo sicuro, verifica la firma RPM, assicurandosi così che essi non siano stati alterati, e successivamente li aggiorna. L'installazione del pacchetto può verificarsi immediatamente oppure può essere programmato durante un periodo ben determinato. Red Hat Network necessita di un System Profile per ogni macchina che desiderate aggiornare. Il System Profile contiene informazioni hardware e software. Queste informazioni sono riservate e non vengono quindi divulgate. Esse sono usate per determinare quali aggiornamenti degli errata sono applicabili per ogni sistema. Senza queste informazioni, Red Hat Network non è in grado di determinare se il vostro sistema ha bisogno di aggiornamenti. Quando viene emesso un errata riguardante la sicurezza (o qualsiasi tipo di errata),red Hat Network vi invierà una con la sua descrizione, indicandovi anche i sistemi che saranno colpiti. Per apportare un aggiornamento, potete usare il Red Hat Update Agent oppure organizzare l'aggiornamento del pacchetto attraverso il sito web Suggerimento Red Hat Enterprise Linux includes the Red Hat Network Alert Notification Tool, a convenient panel icon that displays visible alerts when there is an update for a 114

122 2.1. Aggiornare i pacchetti registered Red Hat Enterprise Linux system. Refer to the following URL for more information about the applet: Importante Prima di installare qualsiasi errata di sicurezza, assicurarsi di leggere qualsiasi istruzione speciale contenuta nell'errata report ed eseguitela scrupolosamente. Consultare Sezione 2.1.5, Applicare i cambiamenti per istruzioni generali su come applicare i cambiamenti fatti da un errata update Come usare il sito web Red Hat Errata Quando vengono emessi gli errata report riguardanti la sicurezza, essi vengono pubblicati sul sito web Red Hat Errata disponibile su Da questa pagina selezionate il prodotto e la versione per il vostro sistema, e successivamente selezionare security nella parte superiore della pagina, per visualizzare solo il Red Hat Enterprise Linux Security Advisories. Se uno dei commenti è un pacchetto usato sul vostro sistema, selezionatelo per ottenere maggiori informazioni. I dettagli descrivono l'exploit inerenti la sicurezza, insieme con altre istruzioni specifiche necessarie per l'aggiornamento del pacchetto, in modo tale da poter risolvere i problemi di sicurezza che si sono verificati. Per poter scaricare il pacchetto (o pacchetti) aggiornato, fate clic sul link per eseguire un login su Red Hat Network, fate clic sul nome del pacchetto e salvatelo sul disco fisso. È fortemente consigliato creare una nuova directory come ad esempio /tmp/updates per poter salvare il pacchetto scaricato Verifica dei pacchetti firmati Tutti i pacchetti di Red Hat Enterprise Linux sono firmati con la chiave Red Hat, Inc. GPG. GPG è l'acronimo di GNU Privacy Guard, o GnuPG, un pacchetto di software libero utilizzato per assicurare l'autenticità dei file distribuiti. Per esempio, una chiave privata (chiave segreta) posseduta da Red Hat, assicura il pacchetto, mentre la chiave pubblica lo verifica. Se la chiave pubblica distribuita da Red Hat non corrisponde con la chiave privata durante la verifica RPM, il pacchetto potrebbe essere stato alterato e quindi non si tratterebbe di un pacchetto fidato. L'utility RPM all'interno di Red Hat Enterprise Linux, prova automaticamente la verifica della firma GPG di un pacchetto RPM prima d'installarlo. Se la chiave GPG di Red Hat non è installata, installatela da un luogo sicuro e statico come ad esempio un CD-ROM d'installazione di Red Hat Enterprise Linux. Assumendo che il CD-ROM è stato montato in /mnt/cdrom, usate il seguente comando per importarlo nel vostro keyring (un database di chiavi fidate presente sul sistema): rpm --import /mnt/cdrom/rpm-gpg-key 115

123 2.1. Aggiornare i pacchetti Per poter visualizzare un elenco di tutte le chiavi installate usate per la verifica dell'rpm, eseguite il seguente comando: rpm -qa gpg-pubkey* Per la chiave di Red Hat, l'output include quanto segue: gpg-pubkey-db42a60e-37ea5438 Per visualizzare i particolari di una chiave specifica, usare il comando rpm -qi seguito dall'output del comando precedente, come riportato in questo esempio: rpm -qi gpg-pubkey-db42a60e-37ea5438 È molto importante controllare la firma dei file RPM prima di procedere alla loro installazione. In questo modo potete assicurarvi che essi non siano stati alterati dalla distribuzione dei pacchetti di Red Hat, Inc.. Per verificare tutti i pacchetti scaricati nello stesso istante, emettere il seguente comando: rpm -K /tmp/updates/*.rpm Per ogni pacchetto,se la chiave GPG esegue una verifica corretta, il comando ritorna gpg OK. Altrimenti, assicuratevi di usare la chiave pubblica di Red Hat corretta, verificando anche la fonte del contenuto. I pacchetti che non passano le verifiche GPG non dovrebbero essere installate, in quanto essi possono essere stati alterati da terzi. Dopo aver verificato la chiave GPG e dopo aver scaricato tutti i pacchetti associati con l'errata report, installateli come utente root ad un promt della shell Installazione dei pacchetti firmati Questo può essere fatto in modo sicuro per la maggior parte dei pacchetti (eccetto per i pacchetti del kernel), emettendo il seguente comando: rpm -Uvh /tmp/updates/*.rpm Per i pacchetti del kernel, è consigliato usare il seguente comando: rpm -ivh /tmp/updates/<kernel-package> Sostituire <pacchetto del kernel> nell'esempio precedente, con il nome dell'rpm del kernel. Una volta riavviata la macchina in modo sicuro usando il nuovo kernel, il vecchio kernel può essere rimosso usando il seguente comando: rpm -e <old-kernel-package> Sostituire <pacchett-kernel-vecchio> nel precedente esempio, con il nome dell'rpm del kernel più vecchio. 116

124 2.1. Aggiornare i pacchetti Nota bene Non è necessario rimuovere il vecchio kernel. Il boot loader di default, GRUB, permette l'installazione di kernel multipli, scelti da un menu al momento dell'avvio. Importante Prima di installare qualsiasi errata di sicurezza, assicurarsi di leggere qualsiasi istruzione speciale contenuta nell'errata report ed eseguitela scrupolosamente. Consultare Sezione 2.1.5, Applicare i cambiamenti per istruzioni generali su come applicare i cambiamenti fatti da un errata update Applicare i cambiamenti Dopo aver scaricato ed installato gli errata tramite il Red Hat Network o il sito web di Red Hat, è importante interrompere l'uso del software più vecchio ed iniziare ad usare quello nuovo. Come eseguire tale operazione dipende dal tipo di software che è stato aggiornato. Il seguente elenco riporta le categorie generali del software e fornisce istruzioni sull'uso delle versioni aggiornate dopo l'aggiornamento di un pacchetto. Nota bene In generale, riavviare il sistema rappresenta il modo più sicuro per assicurarsi che la versione più aggiornata di un pacchetto software venga usata; tuttavia, questa opzione non è sempre disponibile per un amministratore di sistema. Applicazioni Le applicazioni del tipo user-space, sono tutti quei programmi che possono essere iniziati da un utente del sistema. Generalmente tali applicazioni vengono usate solo quando un utente, uno script oppure una utility di un compito automatizzato, vengono lanciati senza persistere per un periodo di tempo prolungato. Una volta aggiornata l'applicazione user-space, interrompete ogni istanza dell'applicazione presente sul sistema, e lanciare nuovamente il programma per usare la versione aggiornata. Kernel Il kernel rappresenta il nucleo della componente software per il sistema operativo di Red Hat Enterprise Linux. Esso gestisce l'accesso alla memoria, al processore, e alle periferiche, programmando anche tutti i vari compiti. A causa del suo ruolo centrale, il kernel non può essere riavviato senza aver fermato il com- 117

125 2.1. Aggiornare i pacchetti puter. Quindi, una versione aggiornata del kernel non può essere usata fino a quando il sistema non viene riavviato. Librerie condivise Le librerie condivise sono delle unità di codice, come glibc, le quali sono usate da un certo numero di applicazioni e di servizi. Le applicazioni che utilizzano una libreria condivisa, generalmente caricano il codice condiviso quando l'applicazione è inizializzata, in questo modo ogni applicazione che utilizza la libreria aggiornata, deve essere interrotta e rilanciata. Per determinare quale applicazione in esecuzione si collega ad una particolare libreria, utilizzare il comando lsof, come riportato nel seguente esempio: lsof /usr/lib/libwrap.so* Questo comando ritorna un elenco di tutti i programmi in esecuzione che usano i wrappert- CP per un controllo dell'accesso host. In questo modo, ogni programma presente nell'elenco, deve essere interrotto e rilanciato se il pacchetto tcp_wrappers è aggiornato. Servizi SysV I servizi SysV sono programmi server persistenti lanciati durante il processo di avvio. Un esempio di servizi SysV sono sshd, vsftpd, e xinetd. Poichè questi programmi generalmente persistono in memoria se la macchina è avviata, ogni servizio SysV aggiornato, deve essere interrotto e rilanciato dopo il miglioramento del pacchetto. Questo può essere fatto usando lo Services Configuration Tool oppure effettuando un log in un prompt della shell root, emettendo il comando /sbin/service come riportato nel seguente esempio: /sbin/service <service-name> restart Nell'esempio precedente, sostituire <nome -servizio> con il nome del servizio, come ad esempio sshd. Servizi xinetd I servizi controllati dal super servizio xinetd possono essere eseguiti solo se vi è un collegamento attivo. Esempi di servizi controllati da xinetd sono Telnet, IMAP, e POP3. A causa del lancio delle nuove istanze di questi servizi, da parte di xinetd ogni volta che si riceve una nuova richiesta, i collegamenti che si verificano dopo un miglioramento sono gestiti dal software aggiornato. Tuttavia, se vi sono collegamenti attivi al momento del miglioramento del servizio controllato da xinetd, essi vengono serviti dalla versione più vecchia del software. Per eliminare le vecchie istanze di un particolare servizio controllato da xinetd, migliorare il pacchetto per il servizio e poi interrompere tutti i processi attualmente in esecuzione. Per determinare se il processo è in esecuzione, usare il comando ps e poi il comando kill o killall per interrompere le istanze correnti del servizio. Per esempio, se i pacchetti imap degli errata della sicurezza vengono emessi, migliorare i pacchetti, e poi inserire il seguente comando come root, in un prompt della shell: ps -aux grep imap 118

126 2.1. Aggiornare i pacchetti Questo comando ritorna tutte le sessioni IMAP attive. Sessioni individuali potranno essere terminate emettendo il seguente comando: kill <PID> Se questo non è in grado di terminare la sessione, utilizzate il seguente comando: kill -9 <PID> Negli esempi precedenti, sostituire <PID> con il numero d'identificazione del processo (presente nella seconda colonna del comando ps) per una sessione IMAP. Per eliminare tutte le sessioni IMAP attive, emettere il seguente comando: killall imapd 119

127 Capitolo 9. Rendere sicura la tua rete <xi:include></xi:include> 1. Wrapper TCP e xinetd Il controllo dell'accesso ai servizi di rete é uno dei fattori che riguardano la sicurezza piú importanti che un amministratore possa incontrare. Fortunatamente, con Red Hat Enterprise Linux sono disponibili un numero di tool creati appositamente per questo. Per esempio, un firewall basato su iptables filtra i pacchetti di rete non desiderati all'interno dello stack di rete del kernel. Per i servizi di rete che lo utilizzano, i wrapper TCP aggiungono un livello di protezione, definendo quale host può collegarsi ai servizi di rete "wrapped". Uno dei servizi di questo tipo é il super serverxinetd. Questo servizio é chiamato super server perché controlla le connessioni per un sottogruppo di servizi di rete, e garantisce un controllo di accesso piú accurato. Figura 9.1, Controllo di accesso per i servizi di rete rappresenta una illustrazione basica di come questi tool lavorano insieme per proteggere i servizi di rete. 120

128 1.1. Wrapper TCP Figura 9.1. Controllo di accesso per i servizi di rete 1.1. Wrapper TCP Il pacchetto dei wrapper TCP (tcp_wrappers viene installato per default e fornisce un controllo d'accesso basato su di un host per i servizi di rete. Il componente piú importante all'interno del pacchetto é la libreria /usr/lib/libwrap.a. In termini generali, un servizio wrapped TCP é stato compilato usando la libreria libwrap.a. Quando si tenta il collegamento ad un servizio wrapped TCP, il servizio prima si riferisce ai file d'accesso dell'host (/etc/hosts.allow e /etc/hosts.deny) per determinare se l'host del client é abilitato al collegamento. In molti casi, il servizio usa il demone syslog (syslogd) per scrivere il nome del client richiedente e del servizio richiesto su /var/log/secure o /var/log/messages. 121