Ricerche IT

Panoramica

Può capitare, alle volte, di trovarci nella necessità di dover fare troubleshooting sulla nostra rete in conseguenza di un qualche malfunzionamento (software o hardware che sia); in alcuni casi, può essere estremamente utile “sniffare” il traffico di rete, cioé avere in una qualche forma comprensibile all’essere umano l’insieme (o, più spesso, un sottoinsieme) delle comunicazioni che avvengono sulla rete.

Per sniffare il traffico su una rete locale (o solo su alcuni hosts della stessa), bisogna innanzitutto avere uno switch che consenta tale attività (cioé uno switch managed), quindi utilizzare un software che consenta l’attività di sniffing vera e propria: il più famoso di questi è senza dubbio Wireshark.

Può succedere però che si debba verificare se il traffico transita o meno sul nostro firewall; in tal caso, è necessario che l’operazione di sniffing avvenga direttamente sul firewall, e a meno che il firewall non sia una macchina Windows o Linux, non è possibile utilizzare Wireshark o tcpdump. Se il firewall è un Cisco ASA, è possibile utilizzare IOS per poter sniffare il traffico, oppure è possibile utilizzare ASDM (ovvero l’interfaccia web di amministrazione), che non ho la più pallida idea di come funzioni; in genere sui firewall Cisco si utilizza la riga di comando.

Sniffing del traffico

Per i miei test su questa funzionalità dell’ASA, ho ripreso l’ambiente di test descritto nel precedente articolo riguardante la VPN IPSEC tra due ASA 5505.

Come prima prova, effettuerò lo sniffing del traffico ICMP dal client su LAN1 al firewall ASA-1. Per farlo dovrò utilizzare il comando capture di IOS; sia questo comando, sia i successivi, vengono eseguiti in privileged mode:

capture traffic_asa1_inside interface inside

dove capture indica il comando da utilizzare per istruire l’ASA sulla cattura del traffico di rete, traffic_asa1_inside è un nome da dare a piacere che indica la singola operazione di sniffing (serve perché potrei voler utilizzare diversi processi di cattura per diversi scopi), interface inside indica l’interfaccia del firewall sulla quale avviene il monitoraggio del traffico; da notare che dando queste indicazioni, viene catturato tutto il traffico di rete.

Fatto questo, pingo, dal client su LAN1, il firewall ASA-1, quindi dovrò vedere sul dispositivo se la cattura avviene correttamente; a questo scopo, devo digitare il seguente comando sull’ASA (dopo aver pingato il firewall, ovviamente):

show capture traffic_asa1_inside

una parte dell’output del comando sarà simile al seguente:

1
2
3
4
5
6
7
8

14: 11:36:14.393961 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
15: 11:36:14.394190 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
16: 11:36:15.399072 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
17: 11:36:15.399210 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
18: 11:36:16.412881 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
19: 11:36:16.413018 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
20: 11:36:17.426812 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
21: 11:36:17.426949 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply

Vorrei porre l’attenzione sul fatto che tutte le righe iniziano con un numero, ma questo numero, nel mio caso, non parte da 1, ma da 14. Questo avviene perché, prima delle mie richieste ICMP, viene loggata l’attività che svolgo sul firewall, in quanto sono loggato allo stesso via SSH, di conseguenza, il comando capture così indicato sniffa tutto il traffico di rete, rendendo più complicata la lettura dell’output restituito. Per ovviare a questo inconveniente, devo limitare il traffico catturato, interrompendo prima di tutto lo sniffing del traffico, con il comando:

no capture traffic_asa1_inside

in questo modo al firewall viene indicato di interrompere la cattura del traffico. Per poter limitare lo sniffing dei pacchetti di rete a determinati protocolli, è necessario utilizzare delle access-list che indichino il tipo di traffico da monitorare, per poi essere utilizzate col comando capture, come mostrato di seguito:

1
2
3
4

configure terminal
access-list test_icmp extended permit icmp any interface inside
exit
capture icmp_asa1_inside access-list test_icmp interface inside

le righe che ci interessano sono la 2 e la 4 (se il significato delle altre due righe non è conosciuto, consultare il precedente articolo riguardante la configurazione di base di un Cisco ASA), in particolare, la riga 2 rappresenta il comando per creare la access list chiamata test_icmp che consente il traffico ICMP tra la rete locale e l’ASA, mentre la riga 4 è la ripetizione del comando capture, con in più l’indicazione di monitorare esclusivamente il traffico consentito dall’access list test_icmp. Se dal mio PC vado a pingare il firewall ASA-1, posso poi dare il comando show capture per verificare il traffico ICMP sull’interfaccia inside:

show capture icmp_asa1_inside

il cui output è questo:

1
2
3
4

1: 12:41:30.148582 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
2: 12:41:31.151572 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
3: 12:41:32.154365 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
4: 12:41:33.155280 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request

In questo caso vedo solamente le richieste ICMP e non le relative risposte, ciò dipende dall’impostazione che ho dato precendentemente all’access-list; se voglio vedere anche le risposte alle richieste ICMP, modificherò l’access-list in questo modo:

1
2
3
4

configure terminal
access-list test_icmp extended permit icmp 192.168.1.0 255.255.255.0 192.168.1.0 255.255.255.0
no access-list test_icmp extended permit icmp any interface inside
exit

Per testare il funzionamento dello sniffing basato sulla access-list cambiata, è meglio pulire tutti i risultati della cattura raccolti fino ad ora:

clear capture icmp_asa1_inside

ora, se pingo il firewall e digito di nuovo il comando show capture mostrato in precedenza, avrò questo output:

1
2
3
4
5
6
7
8

1: 12:48:34.685541 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
2: 12:48:34.685770 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
3: 12:48:35.687037 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
4: 12:48:35.687220 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
5: 12:48:36.688593 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
6: 12:48:36.688730 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
7: 12:48:37.690989 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
8: 12:48:37.691141 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply

In questo caso è decisamente semplice interpretare l’output mostrato dal firewall Cisco, ma se mi trovo a dover sniffare il traffico di diversi protocolli su un link di rete piuttosto trafficato, potrei trovarmi in difficoltà nel capire ciò che avviene. In tal caso, il Cisco ASA ci viene incontro con una simpaticissima funzionalità, che consiste nel poter scaricare un file rappresentante la cattura del traffico visualizzabile con Wireshark. Per poter sfruttare questa funzionalità, è necessario avere il server web abilitato; nel caso non lo fosse, bisogna indicare questi comandi:

1
2
3
4

configure terminal
http server enable
http 192.168.1.0 255.255.255.0 inside
exit

dove la riga 2 rappresenta il comando per abilitare il server web (che rimane in ascolto in modo predefinito in modalità https), mentre la riga 3 indica gli host che possono connettersi via https al firewall e su quale interfaccia, nel nostro caso, gli hosts della rete 192.168.1.0/24 sull’interfaccia inside.

Ora possiamo connetterci tramite un browser all’indirizzo

https://192.168.1.254/capture/icmp_asa1_inside/pcap

dove al posto di icmp_asa1_inside andremo a mettere il nome che abbiamo assegnato alla cattura del traffico tramite il comando capture. Essendo la connessione di tipo https, verrà segnalata l’inaffidabilità del certificato, possiamo proseguire ignorando tranquillamente la segnalazione, dopodiché ci verranno richiesti nome utente e password, ed a quel punto bisogna inserire la password per entrare in privileged mode, senza indicare il nome utente; fatti questi passaggi, ci verrà richiesto di salvare il file pcap, a cui daremo un nome a scelta con estensione .pcap, visualizzabile direttamente con Wireshark. Nei miei test (decisamente poco esaustivi), ho notato come Wireshark mi apra perfettamente i file generati dall’ASA, escludendo però l’ultima riga e restituendo questo errore all’apertura del file .pcap: “The capture file appears to have been cut short in the middle of a packet”; questo errorino comunque non pregiudica una corretta visualizzazione del traffico sniffato.

Conclusioni

La funzionalità di sniffing integrata nel Cisco ASA può risultare molto utile quando si tratta di effettuare troubleshooting su determinate connessioni di rete. In questo articolo ho fatto alcuni test connettendomi al firewall via SSH, ma nel mondo reale, secondo me è caldamente raccomandabile sniffare il traffico connettendosi all’ASA direttamente in console, questo per evitare che eventuali comunicazioni di rete tra il proprio host e il firewall si vadano a sovrapporre al traffico vero e proprio che si vuole monitorare.

Link di riferimento

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00807c35e7.shtml

Lo appunto qui così non mi dimentico.

E’ possibile configurare Apache 2 sotto Debian Lenny per fare rimanere il web server in ascolto su determinate porte e su determinati indirizzi IP, tramite la direttiva Listen. Questa direttiva (o più direttive Listen), in Debian è presente nel file di configurazione /etc/apache2/ports.conf, che viene richiamato tramite una direttiva include dal file principale di configurazione di Apache, /etc/apache2/apache2.conf.

Ad esempio, avendo un server web Debian Lenny con Apache 2, con due indirizzi IP come indicato di seguito:

IP1: 192.168.1.1
IP2: 5.6.7.8

se voglio che il server rimanga in ascolto su tutti e due gli indirizzi sulla porta 80, mi basta lasciare la direttiva predefinita indicata come di seguito:

Listen 80

la quale indica che Apache rimane in ascolto su tutte le interfacce di rete sulla porta 80. Se invece desidero che Apache rimanga in ascolto solamente sull’IP2 sulla porta 80, il contenuto del file ports.conf sarà il seguente:

Listen 5.6.7.8:80

Se invece ho l’esigenza di avere Apache in ascolto su entrambi gli indirizzi IP, ma su porte diverse, il file ports.conf si presenterà così:

Listen 192.168.1.1:80
Listen 5.6.7.8:8080

Dopo ogni modifica al file ports.conf, devo far ripartire Apache con il comando

/etc/init.d/apache2 restart

per applicare le modifiche effettuate.

Avvertenza

Questo articolo è stato redatto a scopo didattico e di test, per cui, si sconsiglia fortemente di adottare questa configurazione in ambiente di produzione, poiché non fornisce i necessari requisiti di sicurezza, a causa del tipo di installazione trattata e NON dei prodotti utilizzati.

Panoramica

In questo articolo verrà trattata l’installazione basilare di un server di posta elettronica su un server Debian Etch. La configurazione proposta rispecchia quella trattata nell’ambiente di test precedentemente descritto, dove verrà preso come server di posta il server Titano, il quale ha l’indirizzo IP 192.168.1.11 e su cui verrà configurato il dominio di posta urano.mail. I prodotti scelti per questa installazione di test sono Postfix, che funge da MTA ed espone il servizio SMTP, e Dovecot, che verrà utilizzato per esporre i servizi POP3 ed IMAP4, per far sì che gli utenti della rete possano consultare la propria posta elettronica. Lo scambio di e-mail avverrà con il server Exchange DCServer (dominio giove.mail) e con il server Linux Giapeto (dominio saturno.mail), il quale verrà configurato allo stesso modo del server Titano.

Cenni teorici

In questo articolo, verranno usati software che permettono la trasmissione e la ricezione di messaggi di posta elettronica. Per scambiare i messaggi tra i vari mail server, il protocollo usato sulla rete Internet è SMTP (Simple Mail Transfer Protocol), il quale, come dice il nome, è responsabile della trasmissione, e ricezione, dei messaggi di posta elettronica tra server di posta. Il server SMTP passa il messaggio ricevuto al Mail Delivery Agent (MDA), che spesso diventa un Local Delivery Agent (LDA), il quale si occupa di depositare il messaggio nella casella di posta elettronica dell’utente locale.

L’archiviazione del messaggio ricevuto, per quanto concerne il mondo Linux / Unix, può avvenire principalmente in due formati, mbox e maildir. Mbox ha la peculiarità di archiviare tutti i messaggi di posta elettronica in un unico file per ogni utente, mentre maildir crea un file per ogni messaggio ricevuto. Entrambi i sistemi presentano vantaggi e svantaggi in termini di flessibilità e prestazioni; a mio parere lo svantaggio principale di mbox è il fatto che, usando un unico file monolitico per ogni casella, in caso di problemi si rischia di perdere l’intero contenuto della casella stessa, cosa che diventa molto più difficile utilizzando maildir.

Un MTA ha il compito di movimentare i messaggi di posta, ma non è in grado di presentarli in una qualche forma all’utente finale. Per raggiungere lo scopo, bisogna installare un server POP3 e/o IMAP4, protocolli che permettono di poter presentare i messaggi di posta in un formato riconoscibile ad una applicazione client installata sull’host dell’utente finale, chiamata client di posta elettronica o Mail User Agent (MUA). POP3 è un protocollo piuttosto datato che consente appunto la lettura della posta elettronica tramite un Mail User Agent, il quale normalmente si connette al server POP3 e scarica i messaggi cancellandoli dal server; tale comportamento è d’ostacolo per quegli utenti che debbono consultare la posta da diverse posizioni, oppure per quegli utenti che condividono l’utilizzo di una mailbox. Per ovviare a questi problemi, esiste il protocollo IMAP4, che mantiene i messaggi di posta sul server, in modo tale da metterli a disposizione a prescindere dalla posizione dalla quale ci si connette; inoltre, mantiene una connessione permanente tra client e server, con i vantaggi del caso, rendendosi quindi il protocollo da scegliere per utilizzi professionali del servizio di posta elettronica.

Nel nostro caso, useremo Postfix come MTA, archiviando la posta nel formato maildir, quindi utilizzeremo Dovecot come server IMAP e POP3 e Outlook e Windows Mail come MUA.

Installazione e configurazione di Postfix

Per installare i software che ci servono, utilizzeremo i pacchetti .deb della distribuzione, in modo da mantenere un ambiente coerente, rinunciando però alle ultime versioni dei software (che è la filosofia di Debian, orientata alla stabilità ed alla sicurezza). Riguardo all’installazione di Postfix, basta un semplice:

apt-get install postfix

che richiede di specificare che tipo d’installazione di Postfix effettuare, noi sceglieremo “Sito Internet”, senza specificare uno smart host, poiché, nell’ambiente di test, non è necessario spedire mail al “mondo reale”:

Figura 1 - Scelta installazione Postfix

dopodiché, ci verrà richiesto il dominio da utilizzare per la posta elettronica, noi indicheremo il dominio urano.mail, come mostrato in figura 2:

Figura 2 - Scelta del dominio

Ora Postfix è installato, si tratta di fare qualche piccolo aggiustamento alla configurazione. Per prima cosa, abilitiamo la rete LAN del server Titano a mandare posta tramite il nostro MTA aggiornando il parametro mynetworks nel file di configurazione /etc/postfix/main.cf, che diventerà così:

mynetworks = 127.0.0.1/8 192.168.1.0/24

Quindi aggiungiamo due parametri, che indicano la directory di spooling delle mail e il formato di archiviazione dei messaggi delle mailbox, scegliendo Maildir, che creerà una directory Maildir per ogni home directory presente sul sistema:

queue_directory = /var/spool/postfix
home_mailbox = $HOME/Maildir/

Fatto questo, chiudiamo e salviamo il file /etc/postfix/main.cf, quindi possiamo far ripartire Postfix tramite il comando:

/etc/init.d/postfix restart

Ora, possiamo creare gli utenti di sistema, che fungeranno anche da mailbox per il server di posta. Gli utenti non hanno bisogno di un accesso shell, per cui verrà fornita loro la shell /bin/false, e faranno parte del gruppo mail:

useradd -m -g mail -s /bin/false salvor.hardin
useradd -m -g mail -s /bin/false hober.mallow

Ora possiamo provare a mandare una mail da un client di posta già configurato nell’ambiente di test all’indirizzo salvor.hardin@urano.mail, se tutto va come deve andare, dando il seguente comando

ls -l /home/salvor.hardin/Maildir/new

dovremmo vedere un file, ed aprendolo con un editor di testo, è possibile leggere il contenuto che altri non è che il testo della mail precedentemente inviata, comprese le intestazioni. A questo punto possiamo considerare terminata la configurazione di Postfix.

Installazione e configurazione di Dovecot

Per verificare il corretto funzionamento di Postfix, abbiamo consultato il file system del server Titano, ma per un utente “normale”, la cosa è alquanto scomoda. Si impone quindi l’installazione di un server POP3 - IMAP che consenta ad un qualsiasi client con installato un MUA di consultare la posta elettronica. La nostra scelta ricade su Dovecot, il quale ha la simpatica caratteristica di cercare di rendere semplice la propria configurazione e di supportare entrambi i formati di archiviazione della posta più diffusi, mbox e maildir. Per installare Dovecot ricorriamo al solito apt:

apt-get install dovecot-common dovecot-popd dovecot-imapd

Fatto questo, come per Postfix, anche con Dovecot dovremo fare qualche piccola modifica al file di configurazione, il cui percorso è /etc/dovecot/dovecot.conf. Per prima cosa, andremo a specificare quali protocolli rendere disponibili con Dovecot, impostando in questo modo la direttiva protocols:

protocols = imap imaps pop3 pop3s

Scendendo poco più giù nel file di configurazione, configureremo Dovecot in modo tale che accetti le password inviate dal client come testo in chiaro (ciò non è molto sicuro ma ci aiuta a semplificarci la vita in questo ambiente di test), impostando questa direttiva:

disable_plaintext_auth = no

Ora dobbiamo impostare il percorso in cui si trovano le caselle di posta ed il formato in cui sono archiviati, nel nostro caso maildir:

mail_location = maildir:~/Maildir

Il resto del file può essere lasciato invariato, quindi salviamo il file e riavviamo il demone Dovecot, tramite il solito

/etc/init.d/dovecot restart

dopodiché possiamo testare il nostro server IMAP configurando un qualsiasi MUA che supporti il protocollo IMAP; io ad esempio, per velocità, ho testato Windows Mail, il client di posta predefinito di Windows Vista, che funziona senza problemi con il server IMAP Dovecot senza bisogno di accorgimenti particolari, se si esclude il fatto che a prima vista sembra non comparire la cartella Posta in arrivo; in questo caso, basta sottoscrivere la cartella Posta in arrivo, la quale comparirà immediatamente rendendo possibile leggere i messaggi presenti nella casella di posta in oggetto.

Considerazioni personali sui MUA per Windows

Siccome, per i miei test, avevo a disposizione Windows Mail, ho utilizzato quello. Ho testato altri client di posta, cominciando da Microsoft Outlook (quello compreso nella suite Office, per intenderci), ed i risultati sono stati sconfortanti. Utilizzando Outlook 2003 per connettermi in IMAP sul server di posta, per prima cosa sul server vengono create solo le cartelle Posta in arrivo e Posta indesiderata, per cui, tra le altre cose, non viene creata la cartella Posta inviata; se anche creiamo la cartella Posta inviata a mano, con Outlook 2003 non c’è modo di archiviare la posta inviata nella cartella sul server.

Inizialmente, non usando praticamente mai IMAP, pensavo che fosse un mio problema, invece, surfando sul Web, ho potuto constatare che si tratta di una “caratteristica” di Outlook, che è aggirabile solamente creando una regola ad hoc. Per me tutto ciò è delirante. Si comporta leggermente meglio invece Outlook 2007, che ha gli stessi difetti di Outlook 2003, ma il cui comportamento relativamente alla posta inviata è modificabile in modo semplice agendo sulla configurazione dell’account di posta. In questo articolo del blog ilcava.it è descritto come procedere in questi casi. Da quanto ho potuto vedere io, anche con Outlook 2007 la cartella Posta inviata va creata a mano.

A questo punto ho voluto provare anche Thunderbird per Windows, che si comporta decisamente meglio, infatti, basta configurare normalmente un account di posta, che crea solamente le cartelle Posta in arrivo e Cestino, ma al primo invio di un messaggio, viene creata automaticamente sul server la cartella Posta inviata, così come viene creata una cartella Drafts se si salva un messaggio come bozza. Come già segnalato, Windows Mail si comporta piuttosto bene con IMAP.

Non ho provato alcun MUA per Linux, ma immagino che non diano particolari problemi.

Se qualcuno tra i lettori ha qualche suggerimento relativamente a quanto scritto con l’utilizzo di Outlook con IMAP, ed in particolare dell’interazione tra Outlook e Dovecot, i commenti sono a disposizione.

Conclusioni

Dopo aver testato con successo il corretto funzionamento di Postfix e Dovecot, possiamo ritenere conclusi, per il momento, i nostri test. Come scritto nell’avvertenza all’inizio dell’articolo, questa configurazione è adatta solamente a scopi (auto)didattici, poiché, configurando in questo modo un server di posta, non abbiamo nessuna protezione contro i virus, contro lo spam e contro il phishing (anche se, soprattutto nell’ultimo caso, la miglior protezione l’abbiamo sopra le spalle, basta usarla), inoltre, non utilizziamo quegli strumenti (come database relazionali o LDAP) per definire domini virtuali e caselle di posta. In poche parole, questa configurazione è decisamente migliorabile, e questi passi in avanti saranno oggetto dei prossimi articoli sull’argomento.

Link di riferimento

• Postfix (home page)
• Dovecot (home page)
• Protocollo SMTP (Wikipedia)
• Protocollo POP3 (Wikipedia)
• Protocollo IMAP (Wikipedia)
• MTA, MDA, MUA (Documentazione Red Hat Linux)
• Configurazione di Postfix (Blog di Marco Buttignon)

In questo articolo viene descritto l’ambiente di test che ho utilizzato e che ho migliorato in questi giorni per poter fare alcuni studi sul funzionamento della posta elettronica su Linux e su Windows, relativamente anche a temi come lo spam ed i virus; lo pubblico qui poiché farò spesso riferimento a questo post nei prossimi articoli. L’ambiente è mostrato in figura 1:

Figura 1 - Ambiente di test

Per prima cosa, tutti i computer mostrati nell’immagine sono macchine virtuali che funzionano su VMWare Server, per cui l’ambiente è totalmente virtualizzato. Si può vedere che esistono due reti, la rete A e la rete B, che hanno questo indirizzamento:

• Rete A: 172.16.1.0/24
• Rete B: 192.168.1.0/24

Le due reti sono state ottenute tramite la funzionalità di Virtual Networking di VMWare Server, perciò, in condizioni normali, le due reti sono separate; in questo caso però, ad unire le due reti, è il firewall Linux, il quale in realtà non fa altro che mettere in comunicazione le due reti tra di loro senza alcun blocco, ma che può essere configurato a piacere con iptables per eventuali regole di restrizione delle comunicazioni di rete. Il firewall Linux inoltre funge da default gateway per ogni host delle due reti, e comunica col mondo Internet tramite il router che si interfaccia con la connessione ADSL, in questo modo, tutti i nodi delle due reti possono accedere alla Rete.

Su entrambe le reti è presente un controller di dominio Windows Server 2003 R2. Entrambi i domain controller fanno parte di un unico dominio (terminus.lan), anche se sono su due reti differenti, inoltre i due server sono posti su due siti Active Directory diversi, questo è utile per i miei test su DFS, che prima o poi dovrei portare a termine. Il domain controller DCServer (Rete A), funge anche da server Exchange, ed inoltre, funge da server DNS per tutti gli host delle due reti, poichè su quel server DNS ho configurato le zone per tutti i domini di posta dell’ambiente di test, definiti sia sul server Exchange sia sui server Linux. Il domain controller Coriolis (Rete B), oltre alle normali funzioni, funge da server SQL Server 2005, che in prima istanza tornerà utile come appoggio per il greylisting sul server Exchange.

Per quanto concerne i due server Linux, in un primo momento verranno configurati come server di posta su due domini separati, mentre più avanti, una volta presa confidenza con la funzionalità di mail server su Linux, configurerò uno dei due server come mail server di “frontiera”, che prenderà in carico la posta, la ripulirà da spam e virus, e quindi la passerà in carico o al server Linux o al server Exchange.

Per la parte client, c’è poco da dire, nel senso che basterà mettere i client su una delle due reti, fare il join al dominio e configurare i client di posta per accedere al mail server del caso.

Su un server Linux, uno strumento indispensabile per l’amministrazione del server stesso è il server SSH, come OpenSSH, tramite il quale possiamo avere un accesso sicuro alla shell del sistema operativo, per poter amministratore comodamente il nostro server Linux.

In ambiente Windows, un accesso SSH non è una cosa indispensabile, risulta più utile avere un accesso via Remote Desktop per amministrare il server, allo stesso tempo però, può comunque avere un senso l’accesso SSH su server Windows, un po’ per determinate operazioni da svolgere via riga di comando, un po’ per poter scaricare o caricare file da o sul server attraverso SCP e SFTP, che possono diventare comodi soprattutto se ci connettiamo al server in remoto, via VPN, oppure se dobbiamo amministrare o trasferire dati da una macchina Linux ad una macchina Windows, in questo modo non saremo costretti ad utilizzare X oppure ad installare Samba per il trasferimento dati da/verso Windows.

Per quanto concerne il software che funge da server SSH, ne esistono diversi, e direi che più o meno tutti sono un’implementazione di SSH in ambiente emulato Cygwin; io ne ho provati due, Freesshd e CopSSH, che rispondono a due esigenze diverse, in particolare, Freesshd fornisce l’ambiente di shell di Windows, mentre CopSSH fornisce un sottoinsieme dei comandi presenti nella shell Bash di Linux.

Personalmente, tra un’implementazione completa della shell di Windows come quella di Freesshd (che appunto richiama direttamente l’interprete dei comandi di Windows, cmd.exe) ed una che (secondo le mie prove, che ammetto non essere state esaustive) risulta, all’atto pratico, avere una parte dei comandi Bash ed una parte dei comandi di Windows, come accade con CopSSH, preferisco Freesshd; tanto per fare un esempio, con Freesshd riesco a vedere i processi in esecuzione con il comando tasklist, cosa che non riesco a fare con Copssh.

Per poter utilizzare un server SSH su Windows, l’utente col quale faccio il logon al server deve obbligatoriamente consentire l’accesso interattivo al server, se così non è, va modificata l’opportuna policy (si tratta di policies diverse a seconda se il server è controller di dominio oppure no) sul server Windows, e questo può comportare qualche problema di sicurezza in più, cosa che secondo me rappresenta il vero svantaggio dell’avere attivo un server SSH su Windows. Entrambi i software hanno una procedura che permette di specificare quali utenti definiti sul server Windows possono accedere via SSH al server stesso, va da sé che, se vogliamo amministrare decentemente il server Windows, dovremo accedere allo stesso con un’utenza amministrativa, se invece necessitiamo del solo SFTP, è sufficiente abilitare l’utente all’accesso, dopodiché saranno le autorizzazioni impostate sulle cartelle del server Windows a stabilire le possibili azioni dell’utente.

Tornando a FreeSSHD, l’installazione del prodotto è decisamente banale, basta cliccare sempre su Avanti (Next); durante l’installazione verrà creato il servizio FreeSSHDService, in modo che il “demone” sia sempre attivo, quindi dovremo accedere alla configurazione del programma, cliccando col tasto destro sull’icona del programma posta nella systray e, scegliendo la voce Settings dal menu contestuale, è possibile gestire il server SSH, e soprattutto, è possibile abilitare o disabilitare l’accesso SSH agli utenti di Windows tramite la scheda Users, come mostrato in figura 1:

Figura 1 - Scheda Users di FreeSSHD

A questo punto, è sufficiente utilizzare un client SSH come Putty in ambiente Windows, o utilizzando il comando ssh in ambiente Linux/Unix, e collegandosi al server (finora ho provato solamente con nome utente e password, senza utilizzare certificati) si può testare il corretto accesso al server Windows.

Purtroppo, per un motivo che non sono ancora riuscito a capire, al primo tentativo viene restituito l’errore “Incoming packet was garbled on decryption” con Putty oppure l’errore “Bad packet length” su Linux, seguito da un numero; la cosa strana è che tentando una seconda volta, senza cambiare nulla, la connessione avviene senza nessun problema, se qualcuno sa o ha idea da cosa possa dipendere, farebbe cosa molto gradita scrivendolo nei commenti.

Una volta verificato il corretto accesso al server Windows, è possibile configurare anche SFTP, andando a specificare nella configurazione di FreeSSHD qual è la directory root SFTP del server Windows tramite la scheda SFTP, come mostrato in figura 2:

Figura 2 - Scheda SFTP di FreeSSHD

Ora non ci resta che testare il corretto funzionamento di una connessione SFTP; per Windows, si possono utilizzare due programmi, WinSCP (che a dispetto del nome consente anche la connessione SFTP) e FileZilla, il quale, oltre alle normali connessioni FTP, permette di stabilire connessioni SFTP basandosi sull’onnipresente Putty.

Questa configurazione, secondo le prove che ho potuto fare, funziona abbastanza bene, con alcuni difetti: per prima cosa, ho letto sul Web che FreeSSHD peccherebbe un po’ in stabilità, finora io non ho avuto problemi, ma non ne ho fatto un uso intensivo; secondariamente, per quanto riguarda SFTP, l’unica configurazione possibile riguarda la root directory accessibile dagli utenti, impedendo agli stessi di poter accedere alle cartelle di livello superiore, e ciò è positivo dal punto di vista della sicurezza, poiché in questo modo si possono abilitare diversi utenti che comunque non hanno la possibilità di gironzolare per il disco, però, allo stesso tempo, questa impostazione riguarda TUTTI gli utenti, per cui anche gli utenti con privilegi amministrativi, utilizzando SFTP, non possono operare ad un livello superiore rispetto alla home directory, anche se, in realtà, utilizzando Linux, è possibile superare questa limitazione utilizzando scp, per poterlo fare però bisogna conoscere il percorso esatto del file da prelevare; altra limitazione, la shell fornita per default da FreeSSHD è quella di Windows, per cui WinSCP non funziona in modalità SCP, funziona però perfettamente in modalità SFTP.

In conclusione, installare un server SSH su Windows, è utile, secondo me, solo in determinate occasioni, soprattutto se da client Linux dobbiamo accedere o condividere file con un server Windows, oppure può risultare utile su connessioni remote particolarmente lente, altrimenti, secondo me è più utile utilizzare Remote Desktop, utilizzabile anche da Linux tramite il pacchetto rdesktop.

Se si deve gestire un firewall Linux con iptables, in determinate situazioni può riverlarsi indispensabile poterne gestire il logging nel modo più lineare possibile; il passo più logico per raggiungere questo scopo è quello di effettuare un logging su file delle attività di iptables che si intende monitorare. Si tenga presente che questi passaggi sono stati effettuati su Debian Etch.

L’operazione consta di più passaggi:

1. configurazione di iptables per fare in modo che venga fatto il logging di determinati tipi di traffico su file;
2. installazione e configurazione di syslog-ng, che consentirà di specificare uno specifico file su cui redirigere il logging di iptables;
3. configurazione di logrotate per poter ruotare i file di log di iptables.

Configurazione di iptables

Per prima cosa, dobbiamo decidere quale tipo di traffico vogliamo monitorare, in questo caso, scegliamo di monitorare il traffico icmp verso l’ipotetica interfaccia esterna del nostro firewall. Se si prende come riferimento l’articolo precedente riguardante iptables, bisogna aggiornare lo script di iptables, caricando per prima cosa il modulo ipt_LOG tramite la direttiva:

modprobe ipt_LOG

Ora è possibile specificare un’istruzione per il logging del traffico ICMP sull’interfaccia esterna, assumendo che questa prenda il nome eth1:

iptables -A INPUT -i eth1 -p icmp -j LOG --log-level 4 --log-prefix='LOG_ICMP '

quest’istruzione è da inserire prima dell’eventuale direttiva che consente o nega il traffico ICMP verso l’interfaccia eth1. Da notare la direttiva log-prefix, che farà precedere le stringhe di logging da ciò che abbiamo specificato tra apici (nel nostro caso LOG_ICMP ). Con questo comando termina la configurazione di iptables.

Installazione e configurazione di syslog-ng

In questo secondo passaggio andremo a sostituire il server syslog classico con syslog-ng, un server syslog più evoluto che permette una gestione più raffinata dei messaggi di log provenienti da kernel e demoni. Prima di configurare syslog-ng, dobbiamo però fare in modo che i log di iptables non compaiano in console (che in pratica si traduce nella comparsa dei vari log sul monitor del PC), cosa decisamente fastidiosa: ciò è possibile editando il file /etc/sysctl.conf:

nano /etc/sysctl.conf

quindi, dobbiamo decommentare la riga 1 del seguente listato sostituendola con la riga 3:

1
2
3

#kernel.printk = 7 4 1 7
 
kernel.printk = 4 4 1 7

in tal modo, indicando il valore 4 in vece del valore 7, si indica che il logging a console viene abilitato solo per il logging di livello inferiore a 4, avendo indicato noi nello script di iptables che il nostro logging è di valore 4, la console rimarrà immacolata.

AGGIORNAMENTO
Un metodo alternativo per raggiungere lo stesso scopo è quello di editare il file /etc/default/syslog-ng decommentando l’ultima riga, che diventerà:

CONSOLE_LOG_LEVEL=4

al posto di 4, potremo mettere, nel caso, anche un numero inferiore fino ad arrivare a 1. Una volta riavviato il demone di syslog-ng, verrà modificato come visto in precedenza il file kernel.printk per prevenire la visualizzazione sulla console dei log di iptables.
FINE AGGIORNAMENTO

Ora, installiamo syslog-ng con il classico apt:

apt-get install syslog-ng

che non si limita ad installare syslog-ng ma disinstalla anche il classico syslog, di cui va a prendere il posto. A questo punto va configurato syslog-ng per far sì che i log non vadano a finire nei file /var/log/messages, /var/log/kern.log e /var/log/syslog, editando il file /etc/syslog-ng/syslog-ng.conf:

nano /etc/syslog-ng/syslog-ng.conf

dove bisogna aggiungere in fondo al file le seguenti righe:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# configurazione logging di iptables
 
destination df_firewall {
        file("/var/log/iptables.log");
};
 
filter f_firewall {
match("LOG_ICMP ");
};
 
log {
        source(s_all);
        filter(f_firewall);
        destination(df_firewall);
};

Le righe da 3 a 5 servono per parametrizzare il file dei log di iptables, le righe da 7 a 9 rappresentano il criterio con cui viene deciso, da parte di syslog-ng, quando redirigere le stringhe di logging verso il file specificato in precedenza attraverso la condizione

match("LOG_ICMP ")

mentre le righe da 11 a 15 rappresentano la direttiva vera e propria verso syslog-ng per loggare tutto ciò che proviene da iptables contenente la stringa “LOG_ICMP “.

Lasciando le cose in questo modo, il logging verso il file /var/log/iptables.log funziona perfettamente, però i log vengono inviati anche verso i file “canonici” di log del kernel. Per ovviare al problema, bisogna modificare il file /etc/syslog-ng/syslog-ng.conf in modo che syslog-ng non scriva i messaggi provenienti da iptables nei file indicati in precedenza; primo passo, la modifica del filtro f_kern:

1
2
3

filter f_kern { facility(kern); };
 
filter f_kern { facility(kern) and not match("LOG_ICMP "); };

dove la riga numero 1 viene sostituita dalla riga numero 3, così da evitare che le voci di log vadano a finire nel file /var/log/kern.log; il passo successivo riguarda la modifica della voce relativa al filtro f_syslog:

1
2
3

filter f_syslog { not facility(auth, authpriv); };
 
filter f_syslog { not facility(auth, authpriv) and not match ("LOG_ICMP "); };

dove andremo a sostituire la riga numero 1 con la riga numero 3, per impedire che il logging di iptables vada a popolare il file /var/log/syslog. Ora rimane da modificare il filtro f_messages, che da così

filter f_messages {
        level(info,notice,warn)
            and not facility(auth,authpriv,cron,daemon,mail,news);
};

diventa così

filter f_messages {
        level(info,notice,warn)
            and not facility(auth,authpriv,cron,daemon,mail,news)
                and not match ("LOG_ICMP ");
};

modifica che inibisce il logging di iptables nel file /var/log/messages. In tutte e tre le situazioni, abbiamo aggiunto la condizione

and not match ("LOG_ICMP ")

condizione che istruisce syslog-ng ad ignorare, per quel determinato filtro, tutti i log che contengono la stringa “LOG_ICMP “, per cui, se si modifica la configurazione di iptables utilizzando, per il logging, un prefisso diverso da quello indicato (tramite la direttiva log-prefix di iptables), tutte le segnalazioni finiranno nei file “normali” e non nel file /var/log/iptables.log che abbiamo creato.

Configurazione di logrotate

Tenendo le cose così come sono, con l’andare del tempo il file /var/log/iptables.log assumerà dimensioni sempre più grandi, rendendo quindi i log di difficile lettura. La soluzione al problema sta nell’istruire logrotate (che dovrebbe essere già presente in Debian Etch) per routare il nostro file di log personalizzato secondo i criteri che preferiamo. Prima di configurare logrotate, vediamo brevemente come funziona.

Logrotate ha un file di configurazione, /etc/logrotate.conf, in cui sono indicate le opzioni generali di configurazione, ed ha una directory, /etc/logrotate.d, in cui vi sono i file di configurazione riguardanti il logging delle singole applicazioni; questi file di configurazione vengono richiamati dalla direttiva presente nel file /etc/logrotate.conf

# packages drop log rotation information into this directory
include /etc/logrotate.d

Nel nostro caso, dovremo creare un file chiamato iptables nella directory /etc/logrotate.d, quindi editarlo per indicare a logrotate come routare il nostro file:

touch /etc/logrotate.d/iptables
nano /etc/logrotate.d/iptables

Nel file /etc/logrotate.d/iptables andremo ad inserire questo contenuto:

1
2
3
4
5
6
7
8

/var/log/iptables.log {
        weekly
        rotate 4
        compress
        notifempty
        missingok
        endscript
}

Vediamo di esaminare nel dettaglio le varie istruzioni del file: weekly indica che il file di log viene routato con cadenza settimanale, rotate 4 significa che vengono conservati 4 log già routati, compress specifica che i file di log routati vengono compressi, notifempty sta ad indicare a logrotate di non routare il file di log se questo è vuoto, missingok permette a logrotate di non segnalare errori se per qualche motivo il file di log non esiste, endscript indica semplicemente il termine delle istruzioni di configurazione per il file corrente. Per ulteriori informazioni sulle opzioni di logrotate è possibile consultare le pagine man di logrotate oppure gli ultimi due collegamenti nella sezione Link di riferimento di quest’articolo.

Ora non rimane che verificare nel tempo il corretto funzionamento di logrotate.

Link di riferimento

http://tuttodebian.blogspot.com/2008/05/iptables-and-syslog-how-to-log-in.html
http://www.linux.it/~rubini/docs/printk/printk.html
http://openskill.info/infobox.php?ID=779
http://www.uielinux.org/blog/14-usare-linux/87-ubuntu-professionale-usiamo-il-logrotate.html

Facendo riferimento al precedente articolo, che trattava la configurazione degli host virtuali in Apache su un sistema Debian, proseguiamo sulla stessa falsariga e vediamo come configurare in modo opportuno un server FTP che consenta una gestione separata dei diversi siti, impedendo nello stesso tempo agli utenti di girare per il file system e quindi di accedere ad aree della macchina che non competono loro; in questo articolo parlerò di ProFTPD, anche se nell’articolo precedente avevo citato vsftpd, purtroppo, nell’installazione in cui ho in funzione vsftpd, ho avuto alcuni problemi di cui non sono riuscito a capire l’origine, problemi che mi hanno costretto ad utilizzare un altro server FTP, ProFTPD appunto.

Ora dobbiamo configurare in modo opportuno ProFTPD in modo da avere due utenti distinti che gestiscano i due siti creati come descritto nell’articolo precedente, creando due siti FTP virtuali, con l’ausilio di un database dedicato su MySQL; installiamo quindi ProFTPD con il supporto per MySQL:

# apt-get install proftpd proftpd-mysql

Ora dovremo creare il database per ProFTPD, entrando in MySQL col comando:

$ mysql -u root -p

quindi, dopo aver inserito la password, creiamo il database proftpd col comando:

> CREATE DATABASE proftpd;

ed ora, creiamo l’utente MySQL proftpd, al quale diamo le autorizzazioni del caso al database proftpd:

> GRANT SELECT, INSERT, UPDATE, DELETE ON proftpd.* TO ‘proftpd’@'localhost’ IDENTIFIED BY ‘pwdProFTPD’;
> FLUSH PRIVILEGES;

dove, al posto di pwdProFTPD metteremo la password che più ci aggrada.

A questo punto, seguiamo le istruzioni contenute nel preziosissimo tutorial di Howtoforge, che spiega passo passo come realizzare un server FTP che permetta di definire dei virtual host, a cominciare dalle indicazioni su come creare un utente ed un gruppo di sistema per ProFTPD, per poi passare alle istruzioni su come creare le tabelle nel database MySQL riguardanti gli utenti e le ftpquotas (le quote di spazio riservato su disco per ogni utente), dopodiché, a pagina 2 della guida, viene spiegato quali righe aggiungere al file di configurazione /etc/proftpd/proftpd.conf per consentire a ProFTPD di utilizzare un database MySQL come supporto. In particolare, vediamo la riga SQLConnectInfo (in cui vanno inseriti i parametri di connessione al database), la quale, se utilizziamo un database MySQL configurato come descritto in precedenza, va scritta così:

SQLConnectInfo proftpd@localhost proftpd pwdproftpd

Giunti qui, dobbiamo inserire gli utenti nel database MySQL, in particolare nella tabella ftpuser (ho tralasciato volutamente la parte riguardante le quote disco); la guida presente su Howtoforge è fatta molto bene, ma ha il difetto di inserire le password degli utenti in chiaro nella tabella del database, cosa che comporta problemi di sicurezza, per cui, dovremo per prima cosa cambiare una direttiva nel file di configurazione di ProFTPD, per poi utilizzare un’istruzione SQL INSERT diversa da quella riportata su Howtoforge. Il primo passaggio, come detto, consiste nel modificare la direttiva SQLAuthTypes, impostandola in questo modo:

SQLAuthTypes Crypt Plaintext

che significa che le password degli utenti definiti nel database MySQL devono essere criptate, altrimenti l’utente non riuscirà ad autenticarsi su ProFTPD. Ora , dopo aver fatto ripartire il demone proftpd, passiamo all’inserimento vero e proprio degli utenti nel database proftpd in MySQL, in cui dobbiamo prestare attenzione ad indicare la home directory su cui verrà rimbalzato l’utente che si autentica su ProFTPD; in particolare, facendo riferimento all’articolo riguardante l’hosting virtuale con Apache, creeremo un utente chiamato u_webtest con password p_webtest (password insicura, utilizzata per comodità) e home directory /var/www/webtest, quindi creeremo un altro utente chiamato u_webprova con password p_webprova e home directory /var/www/webprova:

> INSERT INTO ftpuser (userid, passwd, uid, gid, homedir, shell, count, accessed, modified) VALUES
> (’u_webtest’, ENCRYPT(’p_webtest’), 2002, 2002, ‘/var/www/webtest’, ‘/sbin/nologin’, 0, ”, ”);

> INSERT INTO ftpuser (userid, passwd, uid, gid, homedir, shell, count, accessed, modified) VALUES
> (’u_webprova’, ENCRYPT(’p_webprova’), 2003, 2003, ‘/var/www/webprova’, ‘/sbin/nologin’, 0, ”, ”);

Da notare che per inserire la password è stata usata la funzione di MySQL ‘ENCRYPT’, la quale utilizza la chiamata di sistema crypt() presente sul sistema operativo, quindi di fatto utilizza lo stesso metodo di cifratura utilizzato da Linux per cifrare le password degli utenti di sistema. Ora, rimangono da impostare i permessi sulle directory dei due siti web, per far sì che gli utenti FTP possano scrivere al loro interno, dando l’autorizzazione in scrittura all’utente ftpuser creato in precedenza:

# chown -R ftpuser:www-data /var/www/webtest
# chown -R ftpuser:www-data /var/www/webprova
# chmod -R 775 /var/www/webtest
# chmod -R 775 /var/www/webprova

Arrivati fin qui, dobbiamo solamente utilizzare un client FTP per testare la funzionalità del nostro server FTP, e, se tutto è andato bene, dovremmo essere pronti per utilizzare il nostro ProFTPD.

La corretta gestione dell’ora dei sistemi è molto importante in una rete con un dominio Active Directory, poiché il protocollo di autenticazione predefinito, Kerberos, richiede che l’ora di server e client sia sincronizzata, pena la possibile mancata autenticazione del client, il quale non sarà quindi in grado di fruire dei servizi erogati dal/dai server.

In primis, è buona norma configurare il domain controller che svolge il ruolo di master operazioni PDC in modo tale che prenda l’ora da un riferimento esterno; utilizzando il protocollo Network Time Protocol (NTP), il controllore di dominio sincronizza l’ora, tramite il servizio "Ora di Windows" (W32Time) , con uno o più server NTP, accessibili tramite la rete Internet. Per sincronizzare il controllore di dominio con una o più fonti esterne, è possibile utilizzare la metodica descritta in un precedente articolo. Il passo successivo riguarda la sincronizzazione dei client: se si tratta di postazioni Windows XP e, direi (ma non ho ancora avuto esperienza diretta), Windows Vista, che sono iscritte nel dominio, l’ora sarà sincronizzata automaticamente per impostazione predefinita, prendendo come riferimento il domain controller in questione. Lo stesso avviene per server membri e controller di dominio Windows 2003. Il protocollo utilizzato per questo tipo di sincronizzazione non è NTP ma NT5DS.

In alcuni casi, è possibile che il domain controller non riesca a sincronizzarsi con il/i server NTP, in tal caso, bisogna cercare di capire come mai questo avviene. Il primo passo da seguire, è verificare se non esiste già un’applicazione che utilizza la porta UDP 123, con il comando:

netstat -noa | find "123"

Se ci viene restituita una riga in cui compare un’applicazione che utilizza la porta UDP 123, bisogna segnarsi il PID (Process ID) del processo in questione (ad esempio, 4127), quindi, si utilizza il comando tasklist per identificare quale processo sta utilizzando la porta 123:

tasklist | find "4127"

e così sapremo quale applicazione utilizza la porta 123.

Se invece non risulta nessuna applicazione che utilizza la porta UDP 123, dovremo cercare di capire che avviene durante la sincronizzazione dell’ora. A tal fine, si può abilitare la registrazione del debug del servizio Ora di Windows, andando ad aggiungere alcuni parametri nella chiave del registro di sistema

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

Questi parametri consistono nell’aggiunta di nuovi valori stringa chiamati FileLogSize, FileLogName e FileLogEntries, i cui dati valore sono indicati nella relativa pagina della Knowledge Base Microsoft. Dopo aver aggiunto questi valori, riavviare il servizio Ora di Windows col comando

net stop w32time && net start w32time

quindi digitare il comando

w32tm /resync

per forzare la sincronizzazione dell’ora. Fatto ciò, bisogna aprire con un editor di testo il file specificato precedentemente nel parametro FileLogName del servizio Ora di Windows, che ci mostrerà le varie operazioni svolte durante la sincronizzazione, sperando che ciò ci sia d’aiuto per risolvere i problemi di sincronizzazione dell’ora.

Se abbiamo configurato un firewall Cisco ASA 5505 in una piccola rete locale in cui non esiste un server di dominio, possiamo impostare il firewall in modo tale che funga da server DHCP; ovviamente, l’ASA può fornire il servizio DHCP anche se abbiamo un server di rete, ma penso che, normalmente, sia preferibile impostare come server DHCP lo stesso server di rete.

Prima di procedere alla configurazione del servizio DHCP, dobbiamo pianificare le modalità di assegnazione degli indirizzi IP. Se siamo in una rete piccola, e si ritiene inverosimile un deciso incremento dei client della rete locale, non è necessario specificare un range di indirizzi pari a tutta la classe di appartenenza della sottorete assegnata, poiché, con molta probabilità, vi sarà la necessità di dover mettere in rete dispositivi (tipicamente print server o server) che necessitano di indirizzi IP statici, per cui è bene prevedere fin da subito un range di indirizzi da assegnare staticamente, in modo tale da non dover gestire indirizzi riservati sul DHCP.

Ipotizziamo di avere un firewall ASA su una rete configurata nel modo seguente (la stessa del precedente articolo sul firewall Cisco):

in questa situazione, faremo in modo che ai client della rete venga assegnato un indirizzo IP compreso nel range 192.168.40.50 - 192.168.40.100; oltre agli indirizzi IP, assegneremo dinamicamente anche il server DNS ed il default gateway della rete locale.

Il primo passaggio consiste nel configurare il pool degli indirizzi IP assegnati agli host:

(config)# dhcpd address 192.168.40.50-192.168.40.100 inside

Ora dobbiamo assegnare dinamicamente ai client della rete locale i server DNS per la risoluzione dei nomi:

(config)# dhcpd dns 151.99.125.2 151.99.250.2

Il passaggio successivo consiste nell’indicare qual è il router predefinito per gli host della LAN, che altri non è, nel nostro caso, che il nostro firewall:

(config)# dhcpd option 3 ip 192.168.40.254

Arrivati qui, siamo quasi a posto per una configurazione minimale del servizio DHCP sul firewall; l’ultimo passo da compiere riguarda la durata dei parametri assegnati ai client, cioé la durata del lease, specificata in millisecondi. Il valore predefinito del servizio DHCP sull’ASA è di un’ora,un valore un po’ bassino; possiamo allungare la durata del lease ad una settimana, con questo comando:

(config)# dhcpd lease 604800

Ora la configurazione è completa, rimane solamente l’attivazione del servizio DHCP:

(config)# dhcpd enable inside

A questo punto il servizio DHCP è attivo e funzionante, quindi per non perdere la configurazione al riavvio successivo del firewall digitare il comando:

# write memory

che consente di memorizzare in modo permanente la configurazione del Cisco ASA.

Link di approfondimento: http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/dhcp.html

Uno dei possibili utilizzi dell’Asus eeepc (il nuovo subnotebook di Asus con schermo da 7"), è quello di avere un pratico gingillo da portare sempre con sé e da utilizzare, se necessario, per brevi operazioni di amministrazione su server Linux (tramite ssh) o su server Windows, connettendosi con rdesktop su quei server Windows Server 2003 su cui è abilitato Remote Desktop.

Rdesktop è un’utilità già presente sull’installazione predefinita dell’eeepc, che consente appunto di connettersi ad un qualsiasi computer Windows con attivo il servizio RDP; la particolarità di rdesktop presente su eeepc è che… non funziona. Per essere più precisi, rdesktop non ha alcun problema in sé, ma se lanciamo dal terminale il comando:

$ rdesktop -a 16 -f nomeserver

cercando di connetterci ad un server Windows Server 2003, ci viene presentata la schermata di login dove, se inseriamo nome utente e password, ci butta fuori dando un errore "segmentation fault" nella finestra del terminale.

La ragione di quest’errore, è che, per impostazione predefinita, X.org montato sull’eeepc funziona con una profondità di colore di 16 bit, per cui bisogna modificare quest’impostazione lanciando da terminale il comando:

$ sudo kwrite /etc/X11/xorg.conf

e andando a modificare il valore della voce "DefaultDepth", portandolo da 16 a 24. Salvare il file modificato, quindi riavviare X, ad esempio con la combinazione di tasti (brutale ma veloce) CTRL+ALT+BACKSPACE, e, da una finestra di terminale, dare di nuovo il comando:

$ rdesktop -a 16 -f nomeserver

quindi immettere nome utente e password, ed amministrare il proprio server Windows Server 2003 alla risoluzione di 800×480 pixel, non comodissima ma utilizzabile per periodi non troppo lunghi.