Ricerche IT

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.

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

Recentemente mi è accaduta una cosa curiosa, su un PC di un utente, facendo doppio click su un file Excel con estensione .xls, si apre normalmente Excel ma non viene aperto il file, senza nessuna notifica o messaggio d’errore da parte del programma. Provando a cliccare col tasto destro sul file, selezionando la voce "Apri con…" e scegliendo Microsoft Excel dall’elenco, viene visualizzato un messaggio d’errore che indica l’impossibilità di trovare il percorso del file. Se invece si apre Excel, e si va su File -> Apri selezionando dalla finestra di dialogo il file da aprire, la cartella di lavoro si apre normalmente.

Per ritornare ad una situazione decente, è sufficiente andare nelle opzioni di Excel (menu Strumenti -> Opzioni), andare sulla scheda Generale e deselezionare la casella "Ignora altre applicazioni". Se invece si possiede una copia di Excel 2007, bisogna cliccare sul pulsante di Office (cioé la riedizione del pulsante Start di Windows in salsa Office), quindi andare su Opzioni, Avanzate e lì, nell’area Generale, deselezionare la casella "Ignora altre applicazioni".

Così facendo, la cartella di lavoro si aprirà normalmente con un semplice doppio click sul file Excel.

Link di riferimento
http://support.microsoft.com/kb/211494

Normalmente non scrivo post del genere, ma stavolta lo faccio per descrivere l’esperienza quasi mistica dell’aggiornamento della versione di Wordpress di questo blog dalla 2.2.2 all’ultima versione disponibile. Una robusta dose di pigrizia, un’altra dose consistente di imprudenza, mitigata dalla consapevolezza della scarsa importanza per le sorti del genere umano di questo blog, hanno causato un ritardo mostruoso nell’aggiornamento della piattaforma. Queste cose si pagano.

Infatti, dopo aver eseguito il backup di tutta la baracca (backup che si è rivelato poi provvidenziale), aver disattivato i plugin ed aver impostato il tema predefinito, ho aggiornato il tutto: è con notevole sgomento che mi sono accorto che tutte le categorie si erano volatilizzate, o meglio, esistevano i record delle categorie ma aveva perso tutte le denominazioni. A questo punto, dopo tentativi piuttosto stupidi e soprattutto inutili, ho notato che nella tabella wp_terms esistevano appunto i record, ma che il campo name era impostato a null per tutti i record, non solo, i valori del campo term_id corrispondevano perfettamente ai valori del campo cat_ID della vecchia tabella wp_categories; non rimaneva altro che impostare uno scriptino SQL che popolasse per ogni record il campo name e slug (che corrisponde al campo category_nicename della vecchia tabella wp_categories, campo fondamentale poiché rappresenta la parte finale dell’URL della pagina della singola categoria) in corrispondenza del valore adeguato di term_id. Lanciata la query, sono ricomparse le categorie nel giusto ordine, dopodiché ho potuto procedere nell’aggiornare ed attivare i vari plugin (per fortuna ne uso pochi), utilizzare un nuovo plugin per le statistiche, ovvero StatPress, che ha sostituito il valido, ma purtroppo non più aggiornato, WP-SlimStat, ma soprattutto, ho constatato con un bel sospirone di sollievo che il vecchio tema funziona ancora con le poche modifiche che ho apportato.

Dopo questa piccola avventura, direi che il blog funziona come prima, nel caso capitasse a qualcuno di rilevare malfunzionamenti, non esiti a lasciare un commento, grazie!

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.

Se un server Linux Debian viene utilizzato come server Web, è abbastanza probabile che questo ospiti più siti, ed è piuttosto comune che questi siti vengano gestiti da persone diverse, che debbono avere quindi un accesso FTP dedicato per poter caricare i file del proprio sito, e magari poter avere l’accesso al proprio database MySQL tramite PhpMyAdmin, facendo in modo che gli operatori non vadano a gironzolare su directory o database non di loro competenza.

In questo primo articolo (il prossimo tratterà della configurazione del server FTP vsftpd), darò per scontato che siano già installati (tramite il solito apt) Apache2, PHP5, MySQL; ipotizziamo quindi di dover creare due siti, webtest.it e webprova.it, e creiamo le relative directory:

# mkdir /var/www/webtest
# mkdir /var/www/webprova

Ora, create le directory, dobbiamo configurare gli host virtuali in Apache. Apache2, in Debian, consente la configurazione degli host virtuali inserendo un file di configurazione per ogni host virtuale che si intende creare nella directory /etc/apache2/sites-available, per cui, andremo a creare i due file per i due domini:

# touch /etc/apache2/sites-available/webtest.it
# touch /etc/apache2/sites-available/webprova.it

A questo punto, creati i file vuoti, vanno editati con questi contenuti:

File /etc/apache2/sites-available/webtest.it

NameVirtualHost *:80
<VirtualHost *:80 >
ServerAdmin webmaster@webtest.it
ServerName www.webtest.it
DirectoryIndex index.html index.php
DocumentRoot /var/www/webtest
<Directory "/var/www/webtest">
Order Deny,Allow
Allow from all
Options -Indexes
</Directory>
ErrorLog /var/log/apache2/webtest.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webtest.it.log combined
</VirtualHost>

File /etc/apache2/sites-available/webprova.it

<VirtualHost *:80 >
ServerAdmin webmaster@webprova.it
ServerName www.webprova.it
DirectoryIndex index.html index.php
DocumentRoot /var/www/webprova
<Directory "/var/www/webprova">
Order Deny,Allow
Allow from all
Options -Indexes
</Directory>
ErrorLog /var/log/apache2/webprova.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webprova.it.log combined
</VirtualHost>

Ora i due siti sono configurati con impostazioni "normali", vediamo il loro significato:

NameVirtualHost *:80
Serve per definire su quale interfaccia di rete e su quale porta deve rimanere in ascolto l’host virtuale Apache, in questo caso rimane in ascolto su tutte le interfacce sulla porta 80

<VirtualHost *:80 >
Identifica l’apertura della sezione relativa alla configurazione dell’host virtuale, l’indicazione successiva a VirtualHost (*:80) deve essere identica a quella della direttiva NameVirtualHost

ServerAdmin webmaster@webtest.it
Indica l’indirizzo e-mail dell’amministratore del dominio

ServerName www.webtest.it
Rappresenta il nome FQDN del sito, è fondamentale scrivere bene questa voce altrimenti il nostro sito non sarà visibile

DirectoryIndex index.html index.php
Esprime l’ordine di ricerca di determinate pagine Web rappresentanti la home page quando viene fatta da un browser una richiesta del tipo www.webtest.it/ o www.webtest.it/test/, se in queste directory non esiste una pagina chiamata index.html o index.php (o qualsiasi altro nome file indicato nella direttiva DirectoryIndex), Apache restituirà un errore 403 Forbidden se usiamo la direttiva "Options -Indexes" (come effettivamente faremo), oppure, se questa direttiva non viene utilizzata, visualizzeremo i files presenti nella directory

DocumentRoot /var/www/webtest
Indica la directory in cui sono posizionati i file del nostro sito

<Directory "/var/www/webtest">
Identifica l’inizio della configurazione delle autorizzazioni per la directory del sito

Order Deny,Allow
Allow from all
Queste due righe stanno ad indicare che il sito è visibile a tutti

Options -Indexes
Come indicato in precedenza, questa opzione permette di visualizzare un errore 403 di accesso negato se si digita un indirizzo del tipo www.webtest.it/test/ ed in questa directory non esiste un file chiamato con uno dei nomi file indicati nella direttiva DirectoryIndex; se non si specifica questa opzione, sarà visibile il contenuto dell’intera directory, cosa da evitare.

ErrorLog /var/log/apache2/webtest.it.log
LogLevel warn
CustomLog /var/log/apache2/access.webtest.it.log combined
ErrorLog fornisce un percorso per il file di log contenente le segnalazioni di errore che incontra Apache, mentre LogLevel indica la verbosità delle operazioni di logging attraverso un sistema di livelli, di cui "warn" è uno dei più bilanciati; CustomLog identifica la posizione del file di log che registra gli accessi al sito Web.

Giunti qui, andiamo a creare i file di log che abbiamo specificato nei file di configurazione dei virtual hosts:

# touch /var/log/apache2/access.webtest.it.log
# touch /var/log/apache2/webtest.it.log
# touch /var/log/apache2/access.webprova.it.log
# touch /var/log/apache2/webprova.it.log

dopodiché, bisogna abilitare i siti virtuali, e ciò è possibile tramite il comando a2ensite, il quale crea dei link simbolici nella cartella /etc/apache2/sites-enabled/ che puntano ai file di configurazione creati in precedenza nella cartella /etc/apache2/sites-available/:

# a2ensite webtest.it
# a2ensite webprova.it

ciò è necessario poiché nel file di configurazione di Apache (/etc/apache2/apache2.conf) vi è una direttiva che include i file presenti nella cartella /etc/apache2/sites-enabled/.

Ora non rimane altro che riavviare Apache ed avremo i nostri virtual hosts funzionanti.

Giunti qui, rimane da fare un’unica cosa, cioé installare e configurare PhpMyAdmin per poter gestire il proprio database MySQL tramite sito Web. Per installare PhpMyAdmin, possiamo utilizzare il comando

# apt-get install phpmyadmin

dopodiché, dobbiamo creare un alias su ogni sito sul quale vogliamo rendere disponibile PhpMyAdmin; l’alias si rende necessario poiché l’installazione di PhpMyAdmin viene effettuata nella directory /usr/share/phpmyadmin, per cui, o si fa l’alias, oppure si copia la directory phpmyadmin nella directory del sito, ma ciò non conviene, poiché:

1. è un’operazione che dovremmo ripetere per ogni aggiornamento di PhpMyAdmin
2. nel caso di più host virtuali che utilizzano PhpMyAdmin, dovremmo ripetere la copia per ogni host virtuale che utilizza PhpMyAdmin

per cui, è bene utilizzare un alias per ogni virtual host, che mappi una directory virtuale (ad esempio, /phpmyadmin) per ogni host virtuale che utilizza PhpMyAdmin. Configurare l’alias è molto semplice, prendendo ad esempio i file di configurazione dei due domini citati precedentemente, basta aggiungere questa riga dopo l’istruzione DocumentRoot:

Alias /phpmyadmin /usr/share/phpmyadmin

quindi, dopo aver chiuso e salvato il/i file di configurazione, basta far ripartire Apache per poter utilizzare PhpMyAdmin, la cui configurazione esula dagli scopi di questo articolo; in ogni caso, tenere presente che, se PhpMyAdmin è configurato con un livello di sicurezza ‘cookie’, nome utente e password richiesti per entrare in PhpMyAdmin, non sono altro che gli utenti definiti in MySQL, per cui, bisogna fare attenzione alle autorizzazioni che si assegnano ai vari database, onde evitare che certi utenti possano accedere a database non di loro competenza.

Link di riferimento
Gestione Moduli e Virtual Hosts di Apache2 su Debian e Ubuntu
HowTo: Configurazione dei Virtual Hosts (alias) con Apache2 su Debian ETCH

ExMerge è un’utilità fornita da Microsoft, che consente di esportare o importare, da o verso Exchange, cassette postali in formato .PST. Questa utility è utile soprattutto quando è necessario spostare le cassette postali da un server Exchange ad un altro server Exchange, oppure se si vuole fare un "backup dei poverelli" delle cassette di posta, utile se per fare il salvataggio di Exchange abbiamo solo NTBackup, che fa il backup dell’Information Store ma non delle singole caselle di posta.

Per utilizzare ExMerge, dobbiamo assicurarci di non avere nella nostra organizzazione cassette postali superiori ai 2GB; se queste esistono, è necessario ridurre le loro dimensioni, dopodiché, è possibile scaricare ExMerge dal sito Microsoft, file che quindi va scompattato, per poi copiare i file ExMerge.exe e ExMerge.ini nella cartella degli eseguibili dell’installazione di Exchange, "c:\Percorso-Cartella-Installazione-Exchange\bin". Prima di poter eseguire l’utility però, bisogna compiere alcuni passi preliminari:

1. creare e/o modificare un utente che abbia accesso alle cassette postali con i privilegi "Send as" e "Receive as"
2. fermare, se necessario, il servizio SMTP per non ricevere ed inviare messaggi di posta durante la fase di esportazione/importazione
3. effettuare un salvataggio completo dell’Information Store, per poterlo ripristinare in caso di problemi

Il passaggio n. 1 consiste nella creazione di un utente, che chiameremo ExMerge, che possa accedere alle cassette postali di tutti gli utenti con i privilegi "Send as" e "Receive as". Per creare l’utente, utilizzare la console "Active Directory Users and Computers", e da qui rendere l’utente appartenente al gruppo Administrators (già presente di default in ogni installazione di Windows Server 2003), dopodiché, delegare l’amministrazione dell’organizzazione Exchange all’utente ExMerge andando su System Manager, quindi cliccare col tasto destro sul nome dell’organizzazione Exchange e selezionare la voce "Delegate Control", che apre un wizard, da lì aggiungere l’utente ExMerge agli utenti che già hanno la possibilità di amministrare Exchange, avendo cura di assegnargli il ruolo "Exchange Full Administrator", quindi terminare il wizard confermando le scelte effettuate. A questo punto, bisogna fare i conti con le impostazioni predefinite di Exchange Server 2003, che per gli utenti facenti parte di un gruppo amministrativo (come appunto il gruppo Administrators), nega l’autorizzazione "Send As" e "Receive As" sul (o sui) Mailbox Store, per cui, bisogna impostare in modo esplicito le autorizzazioni "Send As" e "Receive As" sul Mailbox Store per l’utente ExMerge, oppure creare un gruppo di protezione specifico per gli utenti che vogliamo abilitare a questo compito, e delegare a questo gruppo l’amministrazione di Exchange. In questo caso, avendo bisogno di un unico utente, possiamo evitare di creare un gruppo di protezione.

Ora eseguire, se necessario, il passaggio numero 2 e fermare il servizio SMTP, per impedire che vengano spediti e ricevuti ulteriori messaggi di posta, che in una fase di migrazione o ripristino possono incasinare per bene le cose, e che comunque possono essere perduti al termine di questa fase. Non rimane altro da fare che effettuare un salvataggio dell’Information Store, o tramite un software di backup o semplicemente copiando il contenuto della cartella mdbdata (o comunque della cartella in cui è posizionato il database delle mailbox di Exchange).

A questo punto, è possibile far partire ExMerge, non con un doppio click ma cliccando col tasto destro sull’eseguibile selezionando la voce "Run as", quindi specificare l’utente ExMerge appena creato e cliccare Ok. Ora possiamo scegliere tra due modalità, la modalità "One Step", che esegue un salvataggio dello store ed un ripristino su un altro server in un unico passaggio - e la modalità "Two Step", che consente di effettuare l’esportazione e l’importazione delle cassette postali in due fasi distinte, utile se vogliamo fare un backup o un restore delle cassette postali sullo stesso server Exchange.

In questo caso, vediamo la modalità Two Step: dopo aver scelto questa voce, viene richiesto se effettuare lo Step 1 (esportazione) o lo Step 2 (importazione), quindi, dopo aver scelto di fare l’esportazione delle cassette postali, specificare il server Exchange dal quale si vogliono estrarre le cassette di posta, indicando anche il Domain Controller del dominio per velocizzare le operazioni, tenere presente però che il DC va indicato con attenzione se ci troviamo in un ambiente multidominio, poiché verranno esportate solamente le cassette postali facenti parte del dominio a cui appartiene il DC indicato nella casella "Domain Controller (DC) Name"

Giunti fin qui, ExMerge richiede quali cassette di posta vogliamo esportare (nel nostro caso tutte), quindi, una volta selezionate le mailbox che ci interessano, andiamo avanti e selezioniamo l’impostazione della lingua di default (nel nostro caso Italiano) e selezioniamo, per maggior sicurezza, anche il flag "Use last mailbox login locale", che consente di utilizzare l’impostazione della lingua utilizzata su una determinata casella durante l’ultimo accesso alla stessa.

Ora dobbiamo selezionare la cartella di destinazione in cui salvare i file .PST delle mailbox, quindi, fatto questo, possiamo procedere con l’estrazione vera e propria, la cui durata dipende ovviamente dal numero di caselle di posta e dal loro "peso". Finita l’esportazione, è possibile controllare il file ExMerge.log per verificare che non vi siano stati errori in questa fase. Se tutto è andato bene, avremo una sorta di backup di tutte le cassette di posta della nostra organizzazione, che sono ripristinabili in ogni momento, con il vantaggio, a differenza di un salvataggio generico dell’Information Store, che possiamo effettuare il restore anche della singola casella postale.

Il restore di una cassetta di posta può essere fatto sempre con ExMerge, e sempre con le stesse modalità descritte in precedenza, tranne che per la scelta dello Step, infatto per effettuare un ripristino deve essere scelto lo Step 2, come mostrato nella figura sottostante:

La cosa a cui dobbiamo prestare attenzione in questa fase, è la modalità di importazione o ripristino della cassette di posta, infatti, quando ci viene richiesto il server Exchange sul quale vogliamo ripristinare le mailbox, è bene, prima di andare avanti, premere il pulsante "Options" e indicare con che modalità avviene il ripristino.

Dall’immagine precedente, è possibile vedere che nella scheda "Import procedure" ci viene richiesto come ripristinare gli elementi della cassetta postale; trattandosi di un ripristino, la cosa più probabile è che si vogliano sovrascrivere gli elementi già presenti, opzione attivabile cliccando su "Replace existing data in target store", anche se la scelta da effettuare dipende sempre dal contesto nel quale ci troviamo. Ora è possibile proseguire seguendo i passi svolti in precedenza, facendo attenzione a selezionare la cartella sorgente dalla quale pescare i file .PST salvati in precedenza, dopodiché è possibile procedere con il restore vero e proprio. Se tutto è andato bene, avremo ripristinato le nostre cassette di posta, in ogni caso, è sempre bene verificare tramite il file di log (ExMerge.log) che non vi siano stati errori non bloccanti.

E’ importante ricordare che il formato del file .PST creato da ExMerge è quello di Outlook 97-2002, per cui, viene a mancare il supporto ai file con dimensioni superiori ai 2GB, come accennato in precedenza; ho avuto un’esperienza del genere, la quale mi ha insegnato che ExMerge non ha apparentemente problemi a creare file .PST maggiori di 2GB, ma poi, quando si tenta di ripristinare la cassetta postale salvata, viene restituito un errore generico che ci informa che l’importazione del file PST non è andata a buon fine, quindi, spulciando il log di ExMerge (il file ExMerge.log, presente nella cartella in cui abbiamo salvato ExMerge.exe, l’eseguibile dell’utilità) troviamo questa riga:

Error configuring message service (MSPST MS) (UNKNOWN ERROR) (CMapiSession::CreateEMSPSTProfile)

Da questa piccola disavventura, si può trarre l’insegnamento che, in caso di utilizzo di ExMerge, è bene verificare, prima di lanciarlo, che le cassette postali di Exchange non superino i 2GB di dimensione; ancor meglio sarebbe utilizzare delle mailbox quota che impediscano di avere cassette postali più grandi di una certa dimensione, ma questo non sempre si può fare, purtroppo molta gente continua ad utilizzare la posta elettronica in modo improprio, tenendo nella propria casella di posta migliaia di messaggi semplicemente temendo la remota possibilità che servano in un imprecisato futuro.

Link di riferimento:
http://blogs.ugidotnet.org/alexblog/articles/24659.aspx (bell’articolo su ExMerge)
http://support.microsoft.com/kb/292509 (impostazione di un gruppo di protezione per l’utilizzo di ExMerge, io ho usato una strada leggermente diversa)
http://technet.microsoft.com/it-it/library/aa997470(EXCHG.65).aspx (strategie e procedure consigliate per ExMerge)

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.

N.B. Sono un principiante nella configurazione di firewall Cisco, per cui è possibile che abbia scritto delle imprecisioni: se così fosse, potete lasciare un commento per correggere le eventuali imprecisioni.

In una rete medio-piccola, una configurazione abbastanza diffusa quando si ha un collegamento ad Internet con più IP pubblici, prevede la messa in funzione di un firewall, il quale consente di:

• separare la rete pubblica dalla rete privata;
• proteggere la rete privata da intrusioni indesiderate;
• utilizzare un unico indirizzo IP pubblico (a parte il router), tramite NAT, per consentire l’accesso verso Internet alla LAN interna;
• monitorare e limitare il traffico in uscita;
• pubblicare servizi come Web server e Mail server;
• eventualmente connettere in VPN sedi remote.

Un firewall funzionale e robusto che si presta bene per questi scopi in infrastrutture non troppo "impegnative" è il Cisco ASA 5505. L’ ASA 5505 è il prodotto di fascia bassa dei firewall marchiati Cisco, che va a sostituire il PIX 501, ed è dotato di otto porte Ethernet, di una porta console, e di tre porte USB riservate per usi futuri. All’interno della confezione del firewall sono presenti il cavo console (da collegare ad un PC via porta seriale) e due cavi di rete. In questo articolo verrà descritto come compiere una configurazione di base del firewall, che avrà la funzione di connettere la rete LAN alla rete Internet, non aprendo nessuna porta verso l’esterno e consentendo a tutto il traffico di uscire dall’interno verso l’esterno. Lo schema di rete è il seguente, in cui sono mostrati anche gli indirizzi IP della rete locale e degli apparati di rete:

Come descritto nello schema, dobbiamo posizionare il firewall tra le rete locale ed il router Internet, per cui dobbiamo configurare il router cambiando gli indirizzi IP delle interfacce di rete, in questo caso Ethernet0/0 e Ethernet0/1 (corrispondenti alle porte 0 e 1 dell’ASA); per farlo, il primo passaggio è quello di connettere, tramite il cavo console, la porta seriale del PC con la porta console del firewall, quindi utilizzare un emulatore di terminale per poter interagire con l’IOS (il sistema operativo Cisco presente sull’ASA) del firewall. Come descritto tempo fa, è possibile utilizzare Putty per svolgere questa funzione, ed è consigliabile utilizzare l’ultimo rilascio del programma, poiché, per quanto mi riguarda, lo ritengo molto più stabile per questo compito rispetto alle release precedenti. Una volta connessi in console, ci si presenterà un prompt del tipo

ciscoasa>

e, giunti qui, non rimane che configurare il firewall! Per prima cosa, controlliamo le caratteristiche del firewall, le porte presenti e la versione di IOS installata con il comando

> show version

Ora possiamo entrare in privileged exec mode, quella modalità che ci dà un accesso completo al firewall ed alla sua configurazione. Per entrare in questa modalità, digitare il comando

> enable

quindi premere il tasto Invio alla richiesta di password. Se la password non viene accettata, significa che la configurazione predefinita del firewall è stata modificata, quindi bisognerà effettuare una operazione di recovery password del dispositivo per poterne rientrare in possesso. Entrati in priviliged exec mode, è possibile, anche per semplice curiosità, dare un’occhiata alla configurazione corrente, digitando il comando

# show running-config

Notare che il prompt ha l’ultimo carattere trasformato in cancelletto (#) rispetto al precedente simbolo di maggiore (>), ciò indica il passaggio in privileged mode. Ora è possibile entrare nella modalità in cui inserire i comandi IOS di configurazione effettiva del firewall con il comando

# configure terminal

Il prompt cambia di nuovo forma, mettendo dopo il nome host la dicitura (config)# per indicare che siamo nella modalità di inserimento dei comandi di configurazione del firewall. Giunti qui, impostiamo il nome host del firewall, utile per identificare in un attimo su quale dispositivo stiamo lavorando, col comando

(config)# hostname firewalltest

Adesso è possibile assegnare gli indirizzi IP alle interfacce di rete dell’ASA, e qui è necessario fare una premessa: come già esposto, l’ASA 5505 ha otto interfacce ethernet, che compongono uno switch Layer 2, quindi non c’è una separazione fisica tra le porte di rete, cosa che in un firewall è da evitare; il Cisco ASA risolve il "problema" assegnando ogni interfaccia di rete ad una VLAN, in modo da separare logicamente le porte ethernet. Tenere presente che con una licenza base, l’ASA 5505 consente di creare al massimo tre VLAN nella modalità routed (la modalità predefinita), così da poter configurare il firewall che separa la rete LAN, la rete Internet ed eventualmente una DMZ. Esaminando la configurazione di default, si può notare che sono previste due VLAN già configurate, Vlan1 e Vlan2, dove Vlan1 rappresenta l’interfaccia di rete sulla LAN, con un contesto di sicurezza 100 (porta sicura) e con indirizzo IP 192.168.1.1, mentre Vlan2 rappresenta l’interfaccia di rete sulla WAN, con un contesto di sicurezza 0 (interfaccia non sicura) e un indirizzo IP assegnato dal server DHCP del provider Internet. Nella configurazione proposta, non cambieremo le impostazioni di base, per cui sfrutteremo la configurazione esistente che prevede due VLAN con due diversi contesti di sicurezza, ma cambieremo gli indirizzi IP come mostrato nello schema di rete; per far questo però, occorre tenere presente che nella configurazione predefinita è attivo un server DHCP, per cui non possiamo cambiare l’indirizzo dell’interfaccia Vlan1 se prima non modifichiamo la configurazione del server DHCP, cambiano l’ambito o eliminandolo, personalmente preferisco tenere il server DHCP della LAN su un server di rete e non sul router, per cui, disattiviamo il server DHCP:

(config)# no dhcpd address 192.168.1.2-192.168.1.254 inside
(config)# no dhcpd enable inside

Ora possiamo configurare l’interfaccia Vlan1 come segue:

(config)# interface vlan1
(config-if)# ip address 192.168.40.254 255.255.255.0
(config-if)# exit

Configurata Vlan1, passiamo alla configurazione di Vlan2. Come esposto prima, Vlan2 cerca un server DHCP del provider Internet, poiché evidentemente Cisco presuppone che il firewall sia connesso ad Internet tramite modem Ethernet, mentre in realtà, nella nostra configurazione, l’ASA è connesso direttamente al router, per cui l’indirizzo IP di Vlan2 è fisso. A tal proposito, per prima cosa disabiliteremo l’assegnazione dei valori dei server DNS e WINS sull’interfaccia outside (Vlan2), quindi procederemo all’assegnazione dell’indirizzo IP prestabilito:

(config)# no dhcpd auto_config outside
(config)# interface vlan2
(config-if)# ip address 111.1.1.2 255.255.255.248
(config-if)# exit

Ora possiamo controllare se la configurazione di rete, almeno dal punto di vista della LAN, è corretta, semplicemente pingando da un PC in LAN l’indirizzo IP del firewall:

ping 192.168.40.254

Se riceviamo la risposta dal firewall, significa che questa prima parte della configurazione è andata a buon fine. Per fare la stessa prova sull’interfaccia outside, o abbiamo un PC sulla stessa rete del firewall (e quindi con un IP pubblico), oppure dobbiamo provare a pingare l’ASA dal router; in genere, tutti i router hanno una sezione di diagnostica dov’è possibile effettuare un ping verso un host, in caso di router Cisco, è possibile effettuare il ping direttamente con il comando ping, che esiste anche su IOS.

Giunti fin qui, dobbiamo completare la configurazione di rete indicando al firewall il proprio gateway predefinito, nel nostro caso il router che consente il collegamento alla rete Internet:

(config)# route outside 0.0.0.0 0.0.0.0 111.1.1.1 1

dove indichiamo che, partendo dall’interfaccia outside, per tutte le destinazioni che non appartengono alla nostra rete, il firewall inoltrerà le richieste verso il router 111.1.1.1 con metrica 1. Eseguito questo comando, è possibile effettuare un ping verso l’indirizzo IP 66.102.9.99 (Google), che ci dovrebbe rispondere senza problemi, se così non è, c’è un errore nella progettazione della rete, o nella programmazione del firewall, o nella connessione fisica tra gli apparati. Arrivati a questo punto, è bene ricordare che i comandi di configurazione fin qui impartiti hanno un effetto immediato sulla configurazione dell’ASA, configurazione però che non viene mantenuta in caso di riavvio dell’apparato, poiché non viene modificata la configurazione di startup presente sulla memoria flash del firewall; per salvare in modo permanente la configurazione, utilizzare il comando

# write memory

Per impartire questa direttiva, sono uscito dal privileged exec mode, ma il comando ha effetto anche in privileged mode; quando si configura il firewall, ricordarsi di dare questo comando di tanto in tanto, giusto per non perdere d’un botto la configurazione già fatta.

A questo punto i client della rete locale possono navigare sul web, poiché il natting è già preconfigurato sull’apparto, per cui la configurazione di rete sarebbe terminata… ma in realtà, sempre dai PC in LAN, non è possibile pingare o fare un traceroute verso host presenti sulla rete Internet, poiché l’ASA non permette in modo predefinito al protocollo ICMP di attraversare le due diverse interfacce; per ovviare al problema (problema fastidioso, che limita molto la possibilità di fare troubleshooting di base in caso di problemi), è necessario configurare una access list (ACL) che consenta il traffico ICMP da qualsiasi sorgente verso qualsiasi destinazione, quindi bisogna applicare l’ACL sull’interfaccia outside dell’ASA:

(config)# access-list acl_icmp extended permit icmp any any
(config)# access-group acl_icmp in interface outside

Ora possiamo considerare terminata la configurazione di rete del firewall, rimangono però da sistemare alcuni aspetti legati alla sicurezza, l’accesso via ssh al firewall, e la riconfigurazione dell’accesso via http(s) all’ASA. Per prima cosa, assegniamo una password per entrare in privileged exec mode con il comando

(config)# enable password testopassword

dove al posto di testopassword va indicata la password scelta per entrare in privileged mode. Ora bisogna assegnare una password per l’accesso via telnet o ssh, che ci servirà per proteggere l’accesso via ssh all’ASA:

(config)# passwd testopassword

dove al posto di testopassword va indicata la password per l’accesso via rete al firewall. Assegnate queste password, vediamo come abilitare l’accesso via ssh, da preferirsi all’accesso via telnet, poiché quest’ultimo non prevede la possibilità di crittografare le connessioni, col traffico quindi perfettamente sniffabile, password comprese:

(config)# crypto key generate rsa modulus 1024
(config)# ssh 192.168.40.0 255.255.255.0 inside
(config)# ssh timeout 30
(config)# ssh version 2

Il primo comando serve per creare le chiavi di sicurezza richieste da SSH con una crittografia a 1024 bit, il secondo comando serve per abilitare l’accesso via SSH all’intera rete locale (giocando con le subnet è possibile restringere ulteriormente l’accesso al firewall), il terzo comando indica il timeout espresso in minuti, mentre il quarto comando serve per forzare l’utilizzo del protocollo ssh versione 2. Utilizzando un qualsiasi client SSH (come Putty), è ora possibile, se l’host appartiene alla rete LAN, connettersi all’ASA utilizzando l’utente pix e la password indicata con il comando passwd.

Ora rimane da vedere l’accesso via http(s) al firewall. La configurazione predefinita abilita questo tipo di accesso alla rete 192.168.1.0/24, rete che non esiste più, quindi si tratta di eliminare l’impostazione precedente e ricrearla utilizzando l’indirizzamento di rete corretto:

(config)# no http 192.168.1.0 255.255.255.0 inside
(config)# http 192.168.40.0 255.255.255.0 inside

Siamo arrivati al termine della configurazione di base del firewall, quindi la nostra rete locale ha ora il pieno accesso alla rete Internet, situazione che presenta diversi svantaggi, visto che sarebbe il caso di restringere ulteriormente l’accesso ad Internet agli utenti della rete locale, argomento che esula dagli scopi di quest’articolo.