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=10.0.1.0 NETMASK=255.255.255.0 IPADDR=10.0.1.27 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:

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=192.168.1.0/24 DSTNET=192.168.2.0/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:

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:

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.

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 BONDING_OPTS="mode=1 miimon=500" BOOTPROTO=none ONBOOT=yes NETWORK=10.0.1.0 NETMASK=255.255.255.0 IPADDR=10.0.1.27 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.

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

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.

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:

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 modificare questo file manualmente.

I file ifcfg-ppp0 hanno all'incirca questo aspetto:

DEVICE=ppp0 NAME=test WVDIALSECT=test MODEMPORT=/dev/modem LINESPEED=115200 PAPNAME=test USERCTL=true ONBOOT=no PERSIST=no DEFROUTE=yes PEERDNS=yes DEMAND=no IDLETIMEOUT=600

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:

Ecco riportati i file di configurazione più utilizzati per le interfacce:

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.

Esistono quattro tipi principali di configurazione per i server dei nomi:

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.

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 3.4, «Uso di rndc».

BIND conserva i propri file di configurazione nelle seguenti posizioni:

Le sezioni successive descrivono in dettaglio i file di configurazione BIND.

Le seguenti istruzioni vengono utilizzate comunemente in /etc/named.conf:

acl <acl-name> { <match-element>; [<match-element>; ...] };

acl black-hats {     
        10.0.2.0/24;     192.168.0.0/24;  };  
        acl red-hats {     10.0.1.0/24;  };  
options {     
        blackhole { black-hats; };     
        allow-query { red-hats; };     
        allow-recursion { red-hats; };  
}

include "<file-name>"

options { <option>; [<option>; ...] }; 

zone <zone-name><zone-class> { <zone-options>; [<zone-options>; ...] };

zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; };

zone "example.com" { type slave; file "example.com.zone"; masters { 192.168.0.1; }; };

Ecco riportata una lista di istruzioni meno usate, disponibili in named.conf

Il seguente é un elenco di tag di commento validi usati all'interno di named.conf:

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:

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:

Le direttive e i record di risorsa, visti individualmente, possono essere difficili da comprendere. 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 86400 @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN NS dns1.example.com. IN NS dns2.example.com. IN MX 10 mail.example.com. IN MX 20 mail2.example.com. dns1 IN A 10.0.1.1 dns2 IN A 10.0.1.2 server1 IN A 10.0.1.5 server2 IN A 10.0.1.6 ftp IN A 10.0.1.3 IN A 10.0.1.4 mail IN CNAME server1 mail2 IN CNAME server2 www IN CNAME server1

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 10.0.1.1 e 10.0.1.2.

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 www.example.com 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; }; };

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 10.0.1.1 a 10.0.1.6 fanno riferimento agli FQDN corrispondenti. Esso è posizionato all'interno di /var/named/example.com.rr.zone.

$ORIGIN 1.0.10.in-addr.arpa. $TTL 86400 @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day 1 IN PTR dns1.example.com. 2 IN PTR dns2.example.com. 5 IN PTR server1.example.com. 6 IN PTR server2.example.com. 3 IN PTR ftp.example.com. 4 IN PTR ftp.example.com.

Questo file di zona viene utilizzato con l'istruzione zone nel file named.conf simile a quello riportato qui di seguito:

zone "1.0.10.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.

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

include "/etc/rndc.key";

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>"; };

Per maggiori informazioni sul file /etc/rndc.conf, controllare la pagina man di rndc.conf.

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:

Se desiderate annullare le impostazioni predefinite nel file /etc/rndc.conf, sono disponibili le seguenti opzioni:

Per ulteriori informazioni su queste opzioni, consultate la pagina man di rndc.

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 3.7.1, «Documentazione installata».

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.

BIND supporta vari metodi di protezione per l'aggiornamento e il trasferimento di zone, in entrambi i server master e slave:

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.

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:

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.

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. In termini generali questi pericoli vengono classificati nel modo seguente:

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.

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:

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.

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.

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.

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.

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.

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:

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 grafica Tool di configurazione dei servizi (system-config-services). Tutti questi tool richiedono un livello d'acceso root.

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 remoto. 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 username@penguin.example.net

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.

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/hostname-maillog. 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:

scp downloads/* username@penguin.example.net:uploads/

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.

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.

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:

ssh -L local-port:remote-hostname:remote-portusername@hostname

Per controllare le email 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.

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 5.2 uses SSH Protocol 2 and RSA keys by default.

The first step in configuring a DHCP server is to create the configuration file that stores the network information for the clients. Use this file to declare options and global options for client systems.

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 DHCP-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 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:

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.

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.

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 192.168.1.0 netmask 255.255.255.0 {
        option routers                  192.168.1.254;
        option subnet-mask              255.255.255.0;

        option domain-name              "example.com";
        option domain-name-servers       192.168.1.1;

        option time-offset              -18000;     # Eastern Standard Time

        range 192.168.1.10 192.168.1.100;
}

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                  192.168.0.254;
    more parameters for EXAMPLE shared-network
    subnet 192.168.1.0 netmask 255.255.252.0 {
        parameters for subnet
        range 192.168.1.1 192.168.1.254;
    }
    subnet 192.168.2.0 netmask 255.255.252.0 {
        parameters for subnet
        range 192.168.2.1 192.168.2.254;
    }
}

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                  192.168.1.254;
   option subnet-mask              255.255.255.0;

   option domain-name              "example.com";
   option domain-name-servers       192.168.1.1;

   option time-offset              -18000;     # Eastern Standard Time

   host apex {
      option host-name "apex.example.com";
      hardware ethernet 00:A0:78:8E:9E:AA; 
      fixed-address 192.168.1.4;
   }

   host raleigh {
      option host-name "raleigh.example.com";
      hardware ethernet 00:A1:DD:74:C3:F2;
      fixed-address 192.168.1.6;
   }
}

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 192.168.1.10 e 192.168.1.100.

default-lease-time 600;
max-lease-time 7200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-name "example.com";

subnet 192.168.1.0 netmask 255.255.255.0 {
   range 192.168.1.10 192.168.1.100;
}

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

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 192.168.1.4;
}

 cp /usr/share/doc/dhcp-<version-number>/dhcpd.conf.sample /etc/dhcpd.conf

Per un elenco completo di dichiarazioni per le opzioni e delle loro funzioni, fate riferimento alla pagina man dhcp-options.

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.

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:

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

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à:

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:

L'uso di queste pratiche di sicurezza provoca i seguenti effetti su come vsftpd affronta queste richieste:

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

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:

Per un elenco completo delle direttive disponibili all'interno del file di configurazione di vsftpd, consultare Sezione 6.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.

Il seguente è un elenco delle direttive che controllano il comportamento generale del demone vsftpd.

Il seguente è un elenco di direttive le quali controllano il comportamento di login e dei meccanismi di controllo dell'accesso.

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.

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.

Il seguente è un elenco di direttive che influenzano le directory.

Il seguente è un elenco di direttive che influenzano le directory.

Il seguente è un elenco di direttive che influenzano il comportamento di vsftpd durante un logging.

Il seguente è un elenco di direttive che influenzano il modo con il quale vsftpd interagisce con la rete.

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.

È 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 (e-mail) 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 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.

Il seguente elenco riporta alcuni dei benefici che si possono ottenere effettuando delle valutazioni dei vari punti deboli.

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.

nmap foo.example.com

Starting nmap V. 3.50 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1591 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 111/tcp open sunrpc 443/tcp open https 515/tcp open printer 950/tcp open oftep-rpc 6000/tcp open X11 Nmap run completed -- 1 IP address (1 host up) scanned in 71.825 seconds

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:

rpm --import /mnt/cdrom/RPM-GPG-KEY

rpm -qa gpg-pubkey*

gpg-pubkey-db42a60e-37ea5438

rpm -qi gpg-pubkey-db42a60e-37ea5438

rpm -K /tmp/updates/*.rpm

rpm -Uvh /tmp/updates/*.rpm

rpm -ivh /tmp/updates/<kernel-package>

rpm -e <old-kernel-package>